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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This document defines the Stage 2 architecture and specification for the CS Fallback and for SMS over SGs for EPS or 
CS Fallback and SMS over S102. The scope of this document includes the architecture enhancements for functionality 
to enable fallback from E-UTRAN access to UTRAN/GERAN CS domain access and to CDMA Ix RTT CS domain 
access, and functionality to reuse of voice and other CS-domain services (e.g. CS UDI video / LCS / USSD) by reuse of 
the CS domain. The functionality specified to support SMS over SGs does not trigger any CS Fallback to 
UTRAN/GERAN. The functionality specified to support SMS over S102 does not trigger any CS Fallback to CDMA 
IxRTT CS domain. 

The architecture enhancements to support CS fallback to CDMA Ix RTT CS domain access for UEs with single and 
dual receiver configurations are specified in Annex B. 

In this Release of the specification no mechanisms are specified to support CS Fallback to both UTRAN/GERAN and 
CDMA IxRTT in the same PLMN. So, even when a UE has the capability to support both CS Fallback to 
UTRAN/GERAN CS domain and CS Fallback to CDMA IxRTT CS domain in a given PLMN, the PLMN implements 
only one of the two. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] apply. A term defined in the 
present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

IxCS: The 3GPP2 legacy circuit Switched signalling system as defined in 3GPP2 X.S0042-0 [22]. 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] apply. An abbreviation defined in 
the present document takes precedence over the definition of the same abbreviation, if any, in TR 2 1 .905 [ 1 ] . 

IxCS IWS Circuit Switched Fallback Interworking solution Function for 3GPP2 IxCS. 

ICS IMS CentraHsed Services 

NEAF Non-EPS Alert Flag. 

SRVCC Single Radio Voice Call Continuity 



Overall Description 



4.1 



General Considerations 



The CS fallback in EPS enables the provisioning of voice and other CS-domain services (e.g. CS UDI video/ LCS/ 
USSD) by reuse of CS infrastructure when the UE is served by E-UTRAN. A CS fallback enabled terminal, connected 
to E-UTRAN may use GERAN or UTRAN to connect to the CS-domain. This function is only available in case 
E-UTRAN coverage is overlapped by either GERAN coverage or UTRAN coverage. 

CS Fallback and IMS-based services shall be able to co-exist in the same operator"s network. 

The ICS architecture as defined in TS 23.292 [25] shall be able to co-exist with utilising CS Fallback as the CS domain 
in the same operator's network. 

This specification also specifies the architecture required for SMS over SGs. The MO SMS and MT SMS are signalled 
over SGs and do not cause any CS Fallback to GERAN/UTRAN RATs, and consequently does not require any 
overlapped GERAN/UTRAN coverage. 

The support of SMS over SGs is mandatory for UE and MME and MSC supporting CS fallback, whereas UE and MME 
and MSC supporting SMS over SGs are not required to support CS fallback. 

NOTE: An MME supporting only SMS over SGs (i.e. not supporting CS fallback) will either reply with "SMS- 
only" or reject an IMSI attach. 



4.2 



Reference Architecture 



The CS fallback and SMS over SGs in EPS function is realized by using the SGs interface mechanism between the 
MSC Server and the MME. 

The SGs interface functionality is based on the mechanisms specified for the Gs interface, TS 23.060 [3]. 




Figure 4.2-1 : EPS architecture for CS fallbacit and SIVIS over SGs 
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NOTE 1: The MGW is not shown in the figure 4.2-1 since neither CS fallback in EPS nor SMS over SGs has any 
impacts on the U-plane handling. 

NOTE 2: SGSN and S3 have additional functionahty related to ISR and CS fallback/SMS over SGs. If ISR is not 
used, this functionality is not required. 

4.2.1 Reference points 

SGs: It is the reference point between the MME and MSC server. The SGs reference point is used for the 

mobility management and paging procedures between EPS and CS domain, and is based on the Gs 
interface procedures. The SGs reference point is also used for the delivery of both mobile originating and 
mobile terminating SMS. Additional procedures for alignment with the Gs reference point are not 
precluded. 

S3: It is defined in TS 23.401 [2] with the additional functionality to support ISR for CS fallback/SMS over 

SGs as defined in this specification. 

4.3 Functional entities 

4.3.1 UE 

The CS fallback capable UE supports access to E-UTRAN/EPC as well as access to the CS domain over GERAN 
and/or UTRAN. 

The SMS over SGs capable UE supports access to E-UTRAN/EPC and may support access to the CS domain over 
GERAN and/or UTRAN. 

The support of SMS over SGs is mandatory for a UE that supports CS fallback, whereas a UE that supports SMS over 
SGs is not required to support CS fallback. 

These UEs support the following additional functions: 

Combined procedures specified in this document for EPS/IMSI attach, update and detach. 

CS fallback and/or SMS over SGs procedures specified in this document for using CS domain services. 

A UE using CS fallback and/or SMS over SGs supports ISR according to TS 23.401 [2]. In particular a UE deactivates 
ISR at reception of LAU accept or at reception of combined RAU/LAU accept response with no ISR indication. 

The coexistence with IMS services for voice/SMS is defined in clause 4.5. 

There are no other CS fallback/SMS over SGs ISR-specifics for the UE compared to ISR description in TS 23.401 [2], 
i.e. if ISR is active the UE can change between all registered areas and RATs without performing update signalling. The 
UE listens for paging on the RAT it is currently camped on. 

4.3.2 IVIIVIE 

The CS fallback and/or SMS over SGs enabled MME supports the following additional functions: 

Deriving a VLR number and LAI from the GUTI received from the UE or from a default LAI. 

- Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE. 

- Initiating IMSI detach at EPS detach. 

Initiating paging procedure specified in this document towards eNodeB when MSC pages the UE for CS 

services. 

Supporting SMS procedures defined in this document. 
Rejecting CS Fallback call request (e.g. due to O&M reasons) 
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An MME that supports CS Fallback uses the LAI and a hash value from the IMSI to determine the VLR number as 
defined in TS 23.236 [23] when multiple MSC/VLRs serve the same LAI. The same hash value/function is used by 
SGSN to determine the VLR number. An MME that supports SMS over SGs may use the same procedure as for CS 
Fallback. 

4.3.3 MSC 

The CS fallback and/or SMS over SGs enabled MSC supports the following additional functions: 

- Maintaining SGs association towards MME for EPS/IMSI attached UE. 

Supporting SMS procedures defined in this document. 

NOTE: The CS Fallback enabled MSC can also be enhanced to support ICS as defined in TS 23.292 [25] and/or 
SRVCC as defined in TS 23.216 [20]. 

4.3.4 E-UTRAN 

The CS fallback enabled E-UTRAN supports the following additional functions: 

Forwarding paging request for CS domain to the UE. 

Directing the UE to the target CS capable cell. 
For SMS over SGs, no specific E-UTRAN functionality is required. 

4.3.5 SGSN 

If the SGSN supports ISR, SGSN shall follow the rules and procedures described in TS 23.401 [2] and TS 23.060 [3] 
with the following additions and clarifications: 

The SGSN shall not send the ISR activated indication at combined RAU/LAU procedure. 

An SGSN that supports Gs uses LAI and a hash value from the IMSI to determine the VLR number as defined in 
TS 23.236 [23] when multiple MSC/VLRs serve the same LAI. The same hash value/function is used by MME to 
determine the VLR number. 

4.3.6 BSS 

If the network supports ISR, the CS fallback enabled BSS exhibits the following behaviour: 

Even if the network is operating in NMO II/III the BSS shall forward Gb interface paging messages onto the 
radio interface. The BSS in a network operating in NMO II/III shall not be configured to use PBCCH. 
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4.4 Control plane 



4.4.1 MME - MSC Server 



SGsAP 






SGsAP 






SCTP 


SCTP 






IP 


IP 






L2 


L2 






L1 


L1 







MME 



SGs 



MSC Server 



Legend: 

SGsAP: This protocol is used to connect an MME to an MSC Server based on tine BSSAP+. 

Stream Control Transmission Protocol (SCTP): TInis protocol transfers signalling messages. 

Figure 4.4.1-1 : SGs Interface 



4.5 



Co-existence with IIVIS services 



A CS Fallback and IMS capable UE shall follow the procedures for domain selection for UE originating session/calls 
according to TS 23.221 [26] 'Domain selection for UE originating sessions / calls'. 

If a UE is configured to use SMS over IP services it shall, if registered to IMS, send SMS over IMS, even if it is 
EPS/IMSI attached. 

NOTE: The home operator has to be able to activate/deactivate the UE configuration to use SMS over IP by 
means of device management in order to allow alignment with HPLMN support of SMS over IP. 



4.6 Emergency Calls 



When UE is performing CS fallback procedure for Mobile Originating Call for the purpose of emergency call, it shall 
indicate to the MME that this CS fallback request is for emergency purpose. MME also indicates to the E-UTRAN via 
the appropriate Sl-AP message that this CS fallback procedure is for emergency purpose. 

NOTE: E-UTRAN may use the emergency indication for selecting a particular radio access network (2G or 3G) 
for CS emergency handling. 



IVIobility IVIanagement 



5.1 



General 



The CS fallback and SMS over SGs in EPS is realized by using the SGs interface mechanism between the MSC Server 
and the MME. 

The use of the "pool-area" concept as specified in TS 23.236 [23] allows to minimize the occurrence of MSC change at 
CS fallback. 



5.2 Attach procedure 



The attach procedure for the CS fallback and SMS over SGs in EPS is realized based on the combined GPRS/IMSI 
Attach procedure specified in TS 23.060 [3]. 
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UE 



MME 



1 . Attach Request 



MSC/VLR 



HSS 



2. Step 3 to step 16 of the Attach procedure specified in TS 23.401 



z 



3. Derive VLR number 



4. Location Update i Request 



2. 



5. Create SGs ass jciation 



6. Location update in CS domain 



7. Location Update 



Accept 



8. Step 17 to step 26 of the Attach procedure specified in TS 23.401 



Figure 5.2-1 : Attach Procedure 

1) The UE initiates the attach procedure by the transmission of an Attach Request (parameters as specified in 
TS 23.401 [2] including the Attach Type and Mobile Station Classmark 2) message to the MME. The Attach 
Type indicates that the UE requests a combined EPS/lMSl attach and informs the network that the UE is capable 
and configured to use CS fallback and/or SMS over SGs. If the UE needs SMS service but not CSFB, the UE 
shall include an "SMS-only" indication in the combined EPS/lMSl Attach Request. See clause 5.4.4. 

2) Step 3 to step 16 of the EPS Attach procedure are performed as specified in TS 23.401 [2]. 

3) The VLR shall be updated according to the combined GPRS/IMSl Attach procedure in TS 23.060 [3] if the 
Attach Request message includes an Attach Type indicating that the UE requests a combined EPS/lMSl attach. 
The MME allocates a default LAI, which is configured on the MME and may take into account the current TAI 
and/or E-CGl and whether the IMSl attach is for both CSFB and SMS, or for SMS only. The MME derives a 
VLR number based on the allocated LAI and on an IMSl hash function defined in TS 23.236 [23]. The MME 
starts the location update procedure towards the new MSC/VLR upon receipt of the subscriber data from the 
HSS in step 2). This operation marks the MS as EPS-attached in the VLR. 

4) The MME sends a Location Update Request (new LAI, IMSl, MME name. Location Update Type) message to 
the VLR. MME name is a FQDN string. 

5) The VLR creates an association with the MME by storing MME name. 

6) The VLR performs Location Updating procedure in CS domain. 

7) The VLR responds with Location Update Accept (VLR TMSI) to the MME. 

8) The EPS Attach procedure is completed by performing step 17 to step 26 as specified in TS 23.401 [2]. Attach 
Accept message includes the parameters as specified in TS 23.401 [2]: VLR TMSI and LAI as allocated in step 3 
above. The existence of LAI and VLR TMSI indicates successful attach to CS domain. 

If the UE requests combined EPS/IMSI Attach Request without the "SMS-only" indication, and if the network 
supports only SMS over SGs, the network shall perform the IMSl attach and the MME shall indicate in the 
Attach Accept message that the IMSl attach is for "SMS-only". When the network accepts a combined 
EPS/IMSI attach without limiting to "SMS-only", the network may provide a "CSFB Not Preferred" indication 
to the UE. 

If the UE requests combined EPS/IMSI Attach Request with the "SMS-only" indication, and if the network 
supports SMS over SGs only or if it supports CSFB and SMS over SGs, the network shall perform the IMSl 
attach and the MME shall indicate in the Attach Accept message that the IMSl attach is for "SMS-only". 

The network provides the "SMS-only" or "CSFB Not Preferred" indications based on locally configured operator 
policies based on e.g. roaming agreement. 
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The UE behaviour upon receiving such indications is described in TS 23.221 [26]. 

NOTE: The case of unsuccessful attach to CS domain is documented in stage 3 specifications, taking into account 
reachability for CS services of UEs that have the user preference to prioritize voice over data services and 
are not configured/supporting to use IMS voice services. 

5.3 Detach procedure 

5.3.1 UE-initiated Detach procedure 

The UE-initiated Detach procedure for the CS fallback and SMS over SGs in EPS is realized based on the MS-Initiated 
Detach Procedure specified in TS 23.060 [3]. 



UE 



MME 



1 . Detach Request 



MSC/VLR 



HSS 



2. Step 2 to step 10 of the UE-initiated Detach procedure for E-UTRAN 
as specified in TS 23.401 



5. Detach Accept 



3. IIVISI Detach Incication 



Q 4. Remove SGs 
association 



6. Step 1 2 to step 14 of the UE-initiated Detach procedure for E-UTRAN 
as specified in TS 23.401 



Figure 5.3.1-1: UE-initiated Detach Procedure 

1) The UE initiates the detach procedure by the transmission of a Detach Request (parameters as specified in 
TS 23.401 [2], Detach Type) message to the MME. Detach Type indicates which type of detach is to be 
performed, i.e., IMSl Detach only or combined EPS and IMSl Detach. 

2) If Detach Request is indicated in step 1, the UE-initiated Detach procedure for E-UTRAN is continued as 
specified in TS 23.401 [2]. 

3) The MME sends an IMSl Detach Indication (IMSl) message to the VLR. 

4) The VLR removes the association with the MME. 

5) The MME sends a Detach Accept message as specified in TS 23.401 [2]. 

6) The UE-initiated Detach procedure for E-UTRAN is completed with step 12 to step 14 as specified in 
TS 23.401 [2]. 



5.3.2 MME-initiated Detach procedure 



The MME-initiated detach procedure for the CS fallback and SMS over SGs in EPS is realized based on the SGSN- 
Initiated Detach Procedure specified in TS 23.060 [3]. 
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UE 



MME 



MSC/VLR 



HSS 



1 .MME-initiated detach as specified in TS 23.401 



2. IMSI Detach Ind 



cation 



(~) 3. Remove SGs association 



Figure 5.3.2-1: MME-initiated Detach Procedure 

1) The MME-initiated Detach procedure is performed as specified in TS 23.401 [2]. 

2) The MME sends an IMSI Detach Indication (IMSI) message to the VLR. 

3) The VLR removes the association with the MME. 

5.3.3 HSS-initiated Detach procedure 

The HSS-initiated detach procedure for the CS fallback and SMS over SGs in EPS is realized based on the HLR- 
Initiated Detach Procedure specified in TS 23.060 [3]. 



UE 



MME 



MSC/VLR 



HSS 



1 . HSS-initiated detach as specified in TS 23.401 



2. IIVISI Detach Incication 



o 



3. Remove SGs 
association 



Figure 5.3.3-1 : IHSS-initiated Detach Procedure 

1) The HSS-initiated Detach procedure is performed as specified in TS 23.401 [2]. 

2) The MME sends an IMSI Detach Indication (IMSI) message to the VLR. 

3) The VLR removes the association with the MME. 
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5.3.4 Administration of tine MME - MSC/VLR Association 

The MME - MSC/VLR association is created at the following occasions: 

- Combined EPS/ IMSI attach in clause 5.2. 
Combined TA/LA Update in clause 5.4. 

The association is updated on the following occasions: 

- When an UE changes MME. 

The MME - MSC/VLR association is removed at the following occasions: 
UE-initiated Detach in clause 5.3.1. 
MME initiated Detach in clause 5.3.2. 
HSS initiated Detach in clause 5.3.3. 
Gs association establishment in 2/3G, see TS 23.060 [3]. 
MSC/VLR receives an LA update via the A or lu interface. 

5.4 TA/LA Update procedure 

5.4.0 General 

When a CS fallback and/or SMS over SGs capable UE is EPS/IMSI attached, it initiates the combined TA/LA 
procedure based on the triggers specified in TS 23.401 [2]. 

When a CS fallback and/or SMS over SGs capable UE is not EPS/IMSI attached, it may initiate a combined TA/LA 
procedure in order to use CS Fallback or SMS over SGs services. 

5.4.1 Combined TA/LA Update Procedure 

NOTE: The combined TA/LA Update procedure for the CS fallback and SMS over SGs in EPS is realized based 
on the combined RA/LA Update procedure specified in TS 23.060 [3]. 



UE 



1. U5 determines to 
irform TAD 



new MME 



2. TAU Request 



old MME 



MSC/VLR 



HSS 



3. Step 4 to step 1 9 of TAU procedure as specified in TS 23.401 



7. TAU Accept 



8. TAU Complete 



4. Location 



Update Reqi est 



5. Locatior 



6. Location Update Accept 



update in CS d 



Dmain 



Figure 5.4.1-1 : Combined TA / LA Update Procedure 
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1) The UE detects a change to a new TA by discovering that its current TAI is not in the list of TAIs that the UE 
registered with the network or the UE's TIN indicates the need for a TAU when re-selecting to E-UTRAN. The 
combined TA/LA Update Procedure is also performed in order to re-establish the SGs association. 

2) The UE initiates the TAU procedure by sending a TAU Request (parameters as specified in TS 23.401 [2] 
including the Update Type and Mobile Station Classmark 2) message to the MME. The Update Type indicates 
that this is a combined Tracking Area/Location Area Update Request or a combined Tracking Area/Location 
Area Update with IMSI attach Request. If the UE needs SMS service but not CSFB, the UE shall include an 
"SMS-only" indication in the combined TA/LA Update procedure, see clause 5.4.4. 

3) Step 4 to step 19 of the EPS TAU procedure are performed as specified in TS 23.401 [2]. 

4) If there is an associated VLR in the MM context, the VLR also needs to be updated. If the association has to be 
established or if the LA changed, the new MME sends a Location Update Request (new LAI, IMSI, MME name. 
Location Update Type) message to the VLR. New LAI is determined in the MME based on the received GUTI 
from the UE. If this GUTI is mapped from a P-TMSI/RAI, the LAI is retrieved from the GUTI without any 
modification by the MME. Otherwise, the MME allocates a default LAI, which is configured on the MME and 
may take into account the current TAI/or E-CGI and whether the IMSI attach is for both CSFB and SMS, or for 
SMS only. The MME retrieves the corresponding VLR number from the determined LAI. If multiple 
MSCA^LRs serve this LAI an IMSI hash function is used to retrieve the VLR number for the LAI as defined in 
TS 23.236 [23]. The Location Update Type shall indicate normal location update. The MME name is a FQDN 
string. 

5) The VLR performs Location Update procedure in CS domain. 

6) The VLR responds with Location Update Accept (VLR TMSI) to the MME. 

7) The MME sends a TAU Accept (parameters as specified in TS 23.401 [2], LAI, VLR TMSI) message to the UE. 
The VLR TMSI is optional if the VLR has not changed. LAI is determined in step 4 above. The presence of the 
LAI indicates to the UE that it is IMSI attached. If the UE requests combined TA/LA Update Request without 
the "SMS-only" indication, and if the network supports SGs for SMS only, the network shall perform the IMSI 
attach and the MME shall indicate in the TAU Accept message that the IMSI attach is for "SMS-only". 

If the UE requests combined TA/LA Update (or combined TA/LA Update with IMSI attach) without the "SMS- 
only" indication, and if the network supports only SMS over SGs, the network shall perform the combined 
TA/LA Update procedure and the MME shall indicate "SMS-only" in the TAU Accept message. However, if the 
network supports CSFB and SMS over SGs and accepts a combined TA/LA Update procedure but does not 
indicate "SMS-only", the MME may provide a "CSFB Not Preferred" indication to the UE. 

If the UE requests combined TA/LA Update (or combined TA/LA Update with IMSI attach) with the "SMS- 
only" indication, and if the network only supports SMS over SGs or if it supports CSFB and SMS over SGs, the 
network shall perform the combined TA/LA Update procedure and the MME shall indicate in the TAU Accept 
message that the combined TA/LA Update procedure is for "SMS-only". 

The network provides the "SMS-only" or "CSFB Not Preferred" indications based on locally configured operator 
policies based on e.g. roaming agreement. 

The UE behaviour upon receiving such indications is described in TS 23.221 [26]. 

8) The UE may send a TAU complete message as specified in TS 23.401 [2] for the TAU procedure. 

5.4.2 Periodic TA and LA Update Procedure 

When the UE is camped on E-UTRAN, periodic LA updates shall not be performed, but periodic TA updates shall be 
performed. In this case, an SGs association is established and the MSC/VLR shall disable implicit detach for EPS- 
attached UEs and instead rely on the MME to receive periodic TA updates. 



When a periodic TA update is not received in the MME, the MME clears the PPF. The lack of periodic TA update may 
be caused by reselection or handover to GERAN/UTRAN when ISR is active. To ensure CS paging can reach the 
EPS/IMSI attached UE: 
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- the UE shall perform combined RA/LA update in NMO I or LAU in NMO II/III when the periodic TAU timer 
expires and the UE is in GERAN/UTRAN (or next returns to coverage in GERAN/UTRAN) and ISR is active. 

the UE shall perform combined RA/LA update in NMO I if the periodic RAU timer expires and the UE is in 
GERAN/UTRAN (or next returns to coverage in GERAN/UTRAN) and ISR is active. 

In addition, when a periodic TA update is not received in the MME, the MME may implicitly detach the UE as 
specified in TS 23.401 [2]. This MME implicit detach does not affect any SGSN attach status. At an implicit detach, the 
MME also releases the SGs association with the MSC/VLR. The MSC continues to maintain the registered LA for the 
UE. The MSC changes to supervise LA updates and pages in the still registered LA when mobile terminated services 
arrive. 

When the UE camps on GERAN/UTRAN it may perform combined RA/LA updates. The combined RA/LA update 
procedures and the conditions for their usage are described in TS 23.060 [3]. 



5.4.3 Non-EPS Alert procedure 



The MSC/VLR may request an MME to report activity from a specific UE. In this case, the MSC/VLR shall send a 
SGsAP Alert Request (IMSI) message to the MME where the UE is currently EPS-attached. 

Upon reception of the SGsAP Alert Request (IMSI) message, the MME shall set NEAF (Non-EPS Alert Flag). If NEAF 
is set for an UE, the MME shall inform the MSC/VLR when the next activity from that UE (and the UE is both IMSI- 
and EPS attached) is detected, and shall clear NEAF. 

If the activity detected by the MME leads to a procedure towards the MSC/VLR, the MME shall just follow this 
procedure. If the activity detected by the MME does not lead to any procedure towards the MSC/VLR, the MME shall 
send an UE Activity Indication (IMSI) message towards the MSC/VLR. 

5.4.4 Void 



5.5 Idle Mode Signalling Reduction 

In relation with CSFB and/or SMS over SGs, ISR is activated only when a SGs association exists between MME and 
MSC/VLR. Once ISR is activated, the UE follows regular ISR behaviour. It may reselect between E-UTRAN and 
GERAN/UTRAN without a need to update the CN. When a mobile terminated service arrives, the MSC/VLR sends a 
paging message via SGs to the MME. The MME pages in the TA(s) registered for the UE, and, the MME uses the S3 
interface to request the SGSN (i.e. the SGSN that has an ISR relation with the MME for that UE) to page the UE in the 
registered RA. When the UE is already connected with the MME, the MME forwards the paging request only to the UE 
via the established signalling connection. 

CSFB and/or SMS over SGs enabled UE includes the "combined EPS/IMSI attach capability" indication as part of the 
"MS Network Capability" in the Attach, RAU or combined RAU/LAU Request message, if the UE has been configured 
to use CSFB service and/or SMS over SGs by operator policy. SGSN stores the "combined EPS/IMSI attach capability" 
indication for ISR operation. If the UE has not been configured to use CSFB or SMS over SGs, the CSFB/SMS over 
SGs capable UE shall not include the "combined EPS/IMSI attach capability" indication in the Attach, RAU or 
combined RAU/LAU Request message to SGSN. 

ISR remains activated until the CSFB/SMS over SGs enabled UE performs a combined RAU/LAU procedure (e.g. a 
UE in NMO I moves to a new RA or LA or the periodic TAU timer expires while the UE is in NMO I of 
GERAN/UTRAN) or separate LAU procedure (e.g. a UE moves to a different LA in NMO II or III or the periodic TAU 
timer expires while the UE is in NMO II/III of GERAN/UTRAN). Normal re-selection between registered RA/rA(s) 
does not cause ISR deactivated condition. When the UE needs to perform a combined RAU/LAU, the SGSN checks the 
"combined EPS/IMSI attach capability" bit in MS Network Capability and if it indicates that CSFB and/or SMS over 
SGs is enabled then SGSN deactivates ISR by not indicating ISR activated in the RAU Accept message, which is a 
regular ISR functionality as specified in TS 23.401 [2]. So an SGSN in a CSFB/SMS over SGs configuration never 
indicates ISR activated in combined RAU procedures for CSFB/SMS over SGs enabled UEs. After a combined RA/LA 
update procedure, the MSC pages via Gs for mobile terminated services. When Gs is not used, the MSC/VLR pages in 
the LA via lu/A for mobile terminated services. 
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If ISR is deactivated and the UE re-selects to E-UTRAN with the TIN indicating "P-TMSI", it initiates a TAU 
procedure, which is a regular ISR functionality as specified in TS 23.401 [2], and ISR can be activated again. The CS 
fallback/SMS over SGs enabled UE shall perform this TAU procedure as a combined TA/LA Update Procedure. 

5.6 Mobility IVIanagement for SIVIS over SGs only UEs 

UEs that need SMS service but not CSFB indicate this specific condition with the "SMS-only" indication in the 
EPS/IMSI Attach Request and combined TA/LA update procedures. This allows an operator to deploy the SGs for SMS 
delivery over LTE only without the need for CSFB support. In addition, this allows the MME to use a dedicated 
algorithm for the selection of the MSC that supports those UEs. 

NOTE: SMS delivery does not cause the terminal to fallback to the CS-capable network. It is possible that only 
certain MSCs in the network (one in minimum) is configured to support SGs when the network only 
supports SMS for SGs operation. However such a minimal configuration can cause inter-MSC location 
updates to be performed at every movement into/out of E-UTRAN coverage. 



6 IVIobile Originating Call 

6.1 General 

This clause describes the mobile originating call procedures for the CS Fallback in EPS. 

6.2 Mobile Originating call in Active Mode - PS HO supported 
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7. PS HO as specified in 23.401 [2] (continuation of execution phase) 



Figure 6.2-1 : CS Call Request in E-UTRAN, Call in GERAN/UTRAN 
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NOTE 1: DTM is not mandatory for CS Fallback to work and is not linked to PS HO. 

la. The UE sends an Extended Service Request (CS Fallback Indicator) to MME. Extended Service Request 
message is encapsulated in RRC and Sl-AP messages. CS Fallback Indicator indicates MME to perform CS 
Fallback. The UE only transmits this request if it is attached to CS domain (with a combined EPS/IMSI Attach) 
and can not initiate an IMS voice session (because e.g. the UE is not IMS registered or IMS voice services are 
not supported by the serving IP-CAN, home PLMN or UE). 

lb. The MME sends an Sl-AP Request message to eNB that includes a CS Fallback indicator. This message 
indicates to the eNB that the UE should be moved to UTRAN/GERAN. 

Ic. The eNB shall reply with Sl-AP Response message. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN 
cell to which PS handover will be performed. 

3. The eNodeB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required 
message to the MME. In the following an inter-RAT handover from E-UTRAN to UTRAN or GERAN as 
specified in TS 23.401 [2] begins. As part of this handover, the UE receives a HO from E-UTRAN Command 
and tries to connect to a cell in the target RAT. The HO from E-UTRAN Command may contain a CS Fallback 
Indicator which indicates to UE that the handover is triggered due to a CS fallback request. If the HO from E- 
UTRAN Command contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, 
then the UE considers that CS fallback has failed. Service Request procedure is considered to be successfully 
completed when PS Handover procedure is completed successfully. 

NOTE 2: During the PS HO the SGSN does not create a Gs association with the MSC/VLR. 

NOTE 3: Service Request procedure supervision timer shall be sufficiently long considering the optional 

measurement reporting at step 2. 

4. Target RAT is UTRAN or GERAN lu mode: If both, the UE and the new cell support enhanced CS 
establishment in DTM a RR connection may be established while in packet transfer mode without release of the 
packet resources, see TS 43.055 [24] clause 6.1.3. Otherwise the network releases all TBFs allocated in the PS 
Handover Command message and moves the UE to Packet Idle mode, see TS 44.060 [12]. The UE establishes 
CS signalling connection by sending an RRC Initial Direct Transfer message as specified in TS 25.331 [7] that 
contains a CM Service Request. The CN Domain Indicator is set to "CS" in the Initial Direct Transfer message. 

Target RAT is GERAN A/Gb mode: The UE establishes an RR connection by using the procedures specified in 
TS 44.018 [4] (i.e. UE requests and is assigned a dedicated channel where it sends a SABM containing a layer 3 
Service Request message to the BSS and the BSS responds by sending a UA). Upon receiving the SABM 
(containing CM Service Request message) the BSS sends a COMPLETE LAYER 3 INFORMATION message 
(containing the CM Service Request message) to the MSC which indicates CS resources have been allocated in 
the GERAN cell. After the establishment of the main signalling link as described in TS 44.018 [4] the UE enters 
either Dual Transfer Mode or Dedicated Mode and the CS call establishment procedure completes. 

5. In case the MSC serving the 2G/3G target cell is different from the MSC that served the UE while camped on 
E-UTRAN, the MSC shall reject the service request, if implicit location update is not performed. The CM 
Service Reject shall trigger the UE to perform a Location Area Update as follows: 

If the target system operates in Network Mode of Operation (NMO) I the UE shall perform a combined 
RA/LA update, as defined in TS 23.060 [3]. In this case, the SGSN establishes a Gs association with the 
MSCA^LR as specified in TS 23.060 [3], which replaces the SGs association with the MME. 

If the target system operates in NMO II or III the UE performs a Location Area Update towards the MSC. In 
this case, the MSC will release the SGs association with the MME. 

6. The UE initiates the CS call establishment procedure. 

7. After the UE moves to a cell in the target RAT, the inter-RAT handover from E-UTRAN to UTRAN or GERAN 
as specified in TS 23.401 [2] is completed. At the end of this handover the UE may trigger the Routing Area 
Update procedure when the sending of uplink packet data is possible. The detailed steps performed are as per 
TS 23.401 [2]. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21], i.e. if the UE is not registered in the current 
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RA/LA, the UE performs combined RA/LA update procedure when the target system operates in NMO I, or LA update 
procedure when the target system operates in NMO II/III. Also for NMO I if the UE performed only RA update due to 
the CS call the UE performs a combined RA/LA update (see TS 23.060 [3], clause 6.3.1) which creates the Gs 
association. 

6.3 Mobile Originating call in Active IVIode - No PS HO support 
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Figure 6.3-1 : CS Call Request in E-UTRAN, Call in GERAN/UTRAN without PS HO 

la. The UE sends an Extended Service Request (CS Fallback Indicator) to the MME. Extended Service Request 
message is encapsulated in RRC and Sl-AP messages. CS Fallback Indicator indicates MME to perform CS 
Fallback. The UE only transmits this request if it is attached to CS domain (with a combined EPS/IMSI Attach) 
and can not initiate an IMS voice session (because e.g. the UE is not IMS registered or IMS voice services are 
not supported by the serving IP-CAN, home PLMN or UE). 

lb. The MME sends an Sl-AP Request message to eNB that includes a CS Fallback Indicator. This message 
indicates to the eNB that the UE should be moved to UTRAN/GERAN. 

Ic. The eNB shall reply with Sl-AP Response message. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN cell to 
which the redirection procedure will be performed. 

3a. If the UE and network support inter-RAT cell change order to GERAN and the target cell is GERAN: The 
eNodeB triggers an inter-RAT cell change order (optionally with NACC) to a GERAN neighbour cell by 
sending an RRC message to the UE. The inter-RAT cell change order may contain a CS Fallback Indicator 
which indicates to UE that the cell change order is triggered due to a CS fallback request. If the inter-RAT cell 
change order contains a CS Fallback Indicator and the UE fails to estabhsh connection to the target RAT, then 
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the UE considers that CS fallback has failed. Service Request procedure is considered to be successfully 
completed when cell change order procedure is completed successfully. 

3b. If the UE or the network does not support inter-RAT handover from E-UTRAN to GERAN/UTRAN nor inter- 
RAT cell change order to GERAN: The eNodeB triggers RRC connection release with redirection to 
GERAN/UTRAN instead of PS HO or NACC. 

NOTE 2: Service Request procedure supervision timer shall be sufficiently long considering the optional 
measurement reporting at step 2. 

4. The eNodeB sends an S 1 UE Context Release Request (Cause) message to the MME. Cause indicates that the 
UE is not available for the PS service. 

5. SI UE Context in the eNodeB is released as specified in TS 23.401 [2]. 

6. The UE moves to the new cell in GERAN/UTRAN and establishes a radio signalling connection. 

If the UE obtains LA information of the new cell (e.g. based on the system information) and the LA of the new 
cell is different from the one stored in the UE, it performs a Location Area Update or a Combined RA/LA 
Update procedure in case the target system operates in Network Mode of Operation (NMO) I. Alternatively, in 
NMO 1, the UE in GERAN may perform LA update over the RR connection instead of combined RA/LA update 
over the packet access, as defined in TS 24.008 [21], clause 4.7.5.2.5, unless enhanced CS establishment in DTM 
is supported. 

If the UE moves to an UTRAN cell and ISR is not active or the RA of the cell is different to the one the UE is 
registered in, the UE performs a Routing Area Update. This can be performed as part of the combined RA/LA 
Update procedure when the LA of the new cell is different from the one stored in the UE and the target system 
operates in NMO I. 

7. If the target RAT is GERAN and DTM is not supported, the UE starts the Suspend procedure specified in 

TS 23.060 [3], clause 16.2.1.1.2. This triggers the SGSN to send a Suspend Request message to the MME. The 
MME returns a Suspend Response to the SGSN, which contains the MM and PDP contexts of the UE. 

8. If PS services are suspended, the MME starts the preservation of non-GBR bearers and the deactivation of GBR 
bearers. 

9. The UE continues with the MO call setup procedure. 

10a. In case the MSC serving the 2G/3G cell is different from the MSC that served the UE while camped on 
E-UTRAN and if the Location Area Update / Combined RA/LA Update was not performed in step 6, the MSC 
shall reject the call setup service request, if implicit location update is not performed. 

10b. A UE detecting that the MSC rejected the service request shall perform the Location Area Update according 
to existing GERAN or UTRAN procedures. 

10c. After completion of the Location Area Update the UE continues with a MO call setup procedure. 

1 1 . After the CS voice call is terminated and if the UE is in GERAN and PS services are suspended, then (as 

specified in TS 23.060 [3]) the UE shall resume PS services by sending a Routing Area Update Request message 
to the SGSN. The Update Type depends on the mode of operation of the GERAN network, e.g. in mode I a 
Combined RA/LA Update is used and in mode II or III Routing Area Update is used. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21], i.e. if the UE is not registered in the current 
RA/LA, the UE performs combined RA/LA update procedure when the target system operates in NMO I, or separate 
LA update and RA update procedures when the target system operates in NMO II/III. Also for NMO I if the UE 
performed only RA update due to the CS call the UE performs a combined RA/LA update (see TS 23.060 [3], 
clause 6.3.1) which creates the Gs association. 

6.4 Mobile Originating call in Idle Mode 

Mobile Originating call in Idle Mode procedure is specified by reusing the Mobile Originating Call in Active mode 
procedure with Extended Service Request (CS Fallback Indicator) to the MME. The UE is transited to ECM- 
CONNECTED mode by following the applicable procedures specified in TS 23.401 [2]. 
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6.5 Returning back to E-UTRAN 



Once CS service ends in CS domain, existing mechanisms can be used to move the UE to E-UTRAN, no specific CS 
Fallback mechanisms are needed. 

When the UE moves to E-UTRAN, if the EPS service was suspended during the CS service, it is resumed according to 
the procedure shown in the figure 6.5-1 below. 



UE/MS 




eNodeB 
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1 . NAS message 






















2. Resume Request 






3. Resume Request Ack 
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Handling NAS mes ;age 





























Figure 6.5-1 : Resume Procedure returning from CS fallbacit no PS IHO 

1 . The UE sends a NAS message, e.g. Service Request or TAU, to the MME. 

2. If the UE context in the MME indicates that UE is in suspended status, the MME sends a Resume Request 
(IMSI) message to the S-GW that requests the resumption of EPS bearers for the UE. 

3. The S-GW acknowledges the Resume Request and clears the UE's suspending status. 

4. The NAS message is processed accordingly. 



7 



Mobile Terminating Call 



7.1 



General 



This clause describes the mobile terminating call procedures for the CS Fallback in EPS. 

The MSC handles the timers, queuing and retransmission for sending the SGsAP-P AGING-REQUEST message on the 
SGs interface in the same way that it handles the sending of a PAGING message on the A or lu interface. As a 
consequence, the MME and (if ISR is active) the SGSN shall not implement local retransmission schemes for this 
paging. 



7.2 



Mobile Terminating call in idle mode 



The procedure for Mobile Terminating Call in idle mode is illustrated in figure 7.2-1. 
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Figure 7.2-1 : Mobile Terminating Call in idle mode 

1. G-MSC receives lAM. 

2. G-MSC retrieves routing information of the terminating UE by Send Routing Info procedures as specified in 

TS 23.018 [5]. 

3. G-MSC sends I AM to the MSC on the terminating side as specified in TS 23.018 [5]. 

4. The MME receives a Paging Request (IMSI, VLR TMSI, Location Information) message from the MSC over a 
SGs interface. The TMSI (or IMSI) received from the MSC is used by the MME to find the S-TMSI which is 
used as the paging address on the radio interface If location information is reliably known by MME (i.e. MME 
stores the list of TAs), the MME shall page the UE in all the TAs. If the MME does not have a stored TA list for 
the UE, the MME should use the location information received from the MSC to page the UE. 

NOTE 1: This procedure takes place before step 3, immediately after MSC receives MAP_PRN from HSS, if pre- 
paging is deployed. 

5. If the MME did not return an "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends a Paging (as specified in TS 23.401 [2]) message to each eNodeB. The Paging 
message includes a suitable UE Identity (i.e. S-TMSI or IMSI) and a CN Domain Indicator that indicates which 
domain (CS or PS) initiated the paging message. In this case it shall be set to "CS" by the MME. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the paging to the eNodeBs and sends Paging Reject towards MSC to stop 
CS Paging procedure and this CSFB procedure stops. 

6. The radio resource part of the paging procedure takes place. The message contains a suitable UE Identity (i.e. 
S-TMSI or IMSI) and a CN Domain indicator. 

7a. The UE establishes an RRC connection and sends an Extended Service Request (CS Fallback Indicator) to 
MME. The UE indicates its S-TMSI in the RRC signalling. The Extended Service Request message is 
encapsulated in RRC and Sl-AP messages. The CS Fallback Indicator indicates to the MME that CS Fallback 
for this UE is required. The MME sends the SGs Service Request message to the MSC containing an indication 
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that the UE was in idle mode (and hence, for example, that the UE has not received any Calling Line 
Identification information). Receipt of the SGs Service Request message stops the MSC retransmitting the SGs 
interface Paging message. 

NOTE 2: In order to avoid the calling party experiencing a potentially long period of silence, the MSC may use the 
SGs Service Request message containing the idle mode indication as a trigger to inform the calling party 
that the call is progressing. 

7b. MME sends Sl-AP: Initial UE Context Setup (UE capabilities, CS Fallback Indicator and other parameters 
specified in TS 23.401 [2]) to indicate the eNodeB to move the UE to UTRAN/GERAN. 

7c. The eNB shall reply with Sl-AP: Initial UE Context Setup Response message. 

8a. If the UE and the network support PS handover: Upon receipt of the Initial UE Context Setup message with a CS 
Fallback Indicator the eNodeB may optionally solicit measurement reports from the UE to determine the target 
cell to which PS handover will be performed. A PS handover is then performed as specified in TS 23.401 [2]. As 
part of this PS handover, the UE receives a HO from E-UTRAN Command that may contain a CS Fallback 
Indicator, which indicates to UE that the handover is triggered due to a CS fallback request. If the HO from E- 
UTRAN Command contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, 
then the UE considers that CS fallback has failed. 

8b. If the UE or the network does not support PS handover:. Upon receipt of the Initial UE Context Setup message 
with a CS Fallback Indicator the eNodeB may optionally solicit measurement reports from the UE to determine 
the target cell to redirect the UE to. After that, based on the UE and network capability supporting NACC, the 
eNB triggers an inter RAT cell change order (optionally with NACC) to a GERAN neighbour cell or releases the 
RRC Connection with redirection info to change to CS capable RATs (RAT, frequency). In this case the UE 
receives an inter-RAT cell change order that may contain a CS Fallback Indicator which indicates to UE that the 
cell change order is triggered due to a CS fallback request. If the inter-RAT cell change order contains a CS 
Fallback Indicator and the UE fails to establish connection to the target RAT, then the UE considers that CS 
fallback has failed. 

8c. If the UE obtains LA information of the new UTRAN/GERAN cell (e.g. based on the system information or 
redirection info) and the LA of the new cell is different from the one stored in the UE, it performs a Location 
Area Update or a Combined RA/LA procedure if the target system operates in Network Mode of Operation 
(NMO) I, according to TS 23.060 [3]. 

If the UE or the network does not support PS handover and the UE moves to an UTRAN cell and ISR is not 
active or the RA of the cell is different to the one the UE is registered in, the UE performs a Routing Area 
Update. This can be performed as part of the combined RA/LA Update procedure when the LA of the new cell is 
different from the one stored in the UE and the target system operates in NMO I. 

8d. The UE responds with a Paging Response message to the MSC as follows: 

If Target RAT is UTRAN or GERAN lu mode, the UE establishes an RRC connection and responds to the 
paging in an RRC Initial Direct Transfer message as specified in TS 25.331 [7]. The CN Domain Indicator is 
set to "CS" in the Initial Direct Transfer message. When received at the RNC, the Paging Response message 
is sent in an RANAP Initial UE message to the MSC. 

If Target RAT is GERAN A/Gb mode: the UE establishes an RR connection by using the procedures 
specified in TS 44.018 [4] (i.e. UE requests and is assigned a dedicated channel where it sends a SABM 
containing a layer 3 Service Request message = PAGING RESPONSE to the BSS and the BSS responds by 
sending a UA). After the establishment of the main signalling link as described in TS 44.018 [4] the UE 
enters either Dual Transfer Mode or Dedicated Mode and the CS call establishment procedure completes. 
When received at the BSC, the Paging Response message is sent in a BSSAP COMPLETE LAYER 3 
INFORMATION message to the MSC as specified in TS 48.008 [6]. 

NOTE 3: The BSS should be prepared to receive a PAGING RESPONSE even when a corresponding PAGING 
REQUEST has not been sent by this BSS. Also, the MSC should be prepared to receive a Paging 
Response after a relatively long time from when the CS Paging Request was sent (step 4). 

9a. In case the MSC serving the 2G/3G cell is the same as the MSC that served the UE while camped on E-UTRAN, 
it shall establish the CS connection. 
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9b. If the MSC that receives the Paging Response is different from the MSC that sent the Paging Request and if the 
Location Area Update / Combined RA/LA Update was not performed in step 8c, the MSC shall reject the Paging 
Response by releasing the A/lu-cs connection. The BSC/RNC in turn releases the signalling connection for CS 
domain. The signalling connection release shall trigger the UE to perform a Location Area Update as follows: 

If the target system operates in Network Mode of Operation (NMO) I the UE shall perform a combined 
RA/LA update, as defined in TS 23.060 [3]. 

If the target system operates in NMO II or III the UE performs a Location Area Update towards the MSC. 

The Location Area Update triggers the Roaming Retry for CS Fallback procedure as defined in clause 7.5. 

Call Forwarding (see TS 23.082 [31]) is performed on the basis of the TS 24.008 [21] signalling received on the 
GERAN/UTRAN cell. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21], i.e. if the UE is not registered in the current 
RA/LA, the UE performs combined RA/LA update procedure when the target system operates in NMO I, or separate 
LA update and RA update procedures when the target system operates in NMO II/III. Also for NMO I if the UE 
performed only RA update due to the CS call the UE performs a combined RA/LA update (see TS 23.060 [3], 
clause 6.3.1) which creates the Gs association. 

7.3 Mobile Terminating call in Active IVIode - PS HO supported 
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Figure 7.3-1 : CS Page in E-UTRAN, Call in GERAN/UTRAN - Preparation Phase 

la. The MSC receives an incoming voice call and responds by sending a Paging Request (IMSI or TMSI, optional 
Caller Line Identification and Connection Management information, CS call indicator) to the MME over a SGs 
interface. The MSC only sends a CS Page for an UE that provides location update information using the SGs 
interface. In active mode the MME has an established SI connection and if the MME did not return the "SMS- 
only" indication to the UE during Attach or Combined TA/LA Update procedures, the MME reuses the existing 
connection to relay the CS Page to the UE. 
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If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the CS Service Notification to the UE and shall send Paging Reject towards 
MSC to stop CS Paging procedure, and this CSFB procedure stops. 

The eNB forwards the paging message to the UE. The message contains CN Domain indicator and, if received 
from the MSC, the Caller Line Identification. 

The MME immediately sends the SGs Service Request message to the MSC containing an indication that the UE 
was in connected mode. The MSC uses this connected mode indication to start the Call Forwarding on No Reply 
timer for that UE and the MSC should send an indication of user alerting to the calling party. Receipt of the SGs 
Service Request message stops the MSC retransmitting the SGs interface Paging message. 

NOTE 1 : The pre-configured policy may be used by UE to avoid being disturbed without Caller Line Identification 
display and the detailed handling is to be decided by CTl and CT6. 

NOTE 2: This procedure can also take place immediately after MSC receives MAP_PRN from HSS, if pre-paging 
is deployed. Caller Line Identification and CS call indicator are also provided in the case of pre-paging. 

lb. UE sends an Extended Service Request (CS Fallback Indicator, Reject or Accept) message to the MME. The 
Extended Service Request message is encapsulated in RRC and Sl-AP messages. CS Fallback Indicator 
indicates to the MME to perform CS Fallback. The UE may decide to reject CSFB based on Caller Line 
Identification. 

Ic. Upon receiving the Extended Service Request (CSFB, Reject), the MME sends Paging Reject towards MSC to 
stop CS Paging procedure and this CSFB procedure stops. 

Id. MME sends an Sl-AP Request message to eNB that includes the UE Radio Capabilities and a CS Fallback 
Indicator. This message: indicates to the eNB that the UE should be moved to UTRAN/GERAN. 

le. The eNB shall reply with Sl-AP Response message. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN 
cell to which PS handover will be performed. 

3. The eNodeB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required 
message to MME. In the following an inter-RAT handover from E-UTRAN to UTRAN or GERAN as specified 
in TS 23.401 [2] begins. As part of this handover, the UE receives a HO from E-UTRAN Command and tries to 
connect to a cell in the target RAT. The HO from E-UTRAN Command may contain a CS Fallback Indicator 
which indicates to UE that the handover was triggered due to a CS fallback request. If the HO from E-UTRAN 
Command contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, then the 
UE considers that CS fallback has failed. 

NOTE 3: During the PS HO the SGSN does not create a Gs association with the MSC/VLR. 

4. If the Target RAT is UTRAN or GERAN lu mode: The UE establishes an RRC connection and responds to the 
paging by sending an RRC Paging Response as specified in TS 25.331 [7]. The CN Domain Indicator is set to 
"CS" in the Initial Direct Transfer message. 

If the Target RAT is GERAN A/Gb mode: The UE establishes an RR connection and responds to paging by 
using the procedures specified in TS 44.018 [4] (i.e. UE requests and is assigned a dedicated channel where it 
sends a SABM containing a Paging Response to the BSS and the BSS responds by sending a UA). Upon 
receiving the SABM (containing a Paging Response message) the BSS sends a COMPLETE LAYER 3 
INFORMATION message (containing a Paging Response message) to the MSC which indicates CS resources 
have been allocated in the GERAN cell. After the establishment of the main signalling link as described in 
TS 44.018 [4] the UE enters Dual Transfer Mode and the CS call establishment procedure completes. 

NOTE 4: The BSS should be prepared to receive a Paging Response even when the corresponding Paging Request 
has not been sent by this BSS. 

5. If the MSC serving the 2G/3G target cell is different from the MSC that served the UE while camped on 
E-UTRAN, the MSC shall reject the Paging Response message by releasing the lu connection for UTRAN or the 
A/Gb connection for GERAN. The BSC/RNC in turn releases the signalling connection for UTRAN or GERAN 
CS domain. The signalling connection release shall trigger the UE to perform a Location Area Update as 
follows: 
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If the target system operates in Network Mode of Operation (NMO) I the UE shall perform a combined 
RA/LA update, as defined in TS 23.060 [3]. In this case, the SGSN establishes a Gs association with the 
MSCA^LR as specified in TS 23.060 [3], which replaces the SGs association with the MME. 

If the target system operates in NMO II or III the UE performs a Location Area Update towards the MSC. In 
this case, the MSC will release the SGs association with the MME. 

The Location Area Update triggers the Roaming Retry for CS Fallback procedure as defined in clause 7.5. 

6. The CS call establishment procedure is initiated. 

7. After the UE moves to a cell in the target RAT, the inter-RAT handover from E-UTRAN to UTRAN or GERAN 
as specified in TS 23.401 [2] is completed. At the end of this handover the UE may trigger the Routing Area 
Update procedure when the sending of uplink packet data is possible. The detailed steps performed are as per 
TS 23.401 [2]. 

With the exception of steps la and Ic, above. Call Forwarding (see TS 23.082 [31]) is performed on the basis of the 
TS 24.008 [21] signalling received on the GERAN/UTRAN cell. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21], i.e. if the UE is not registered in the current 
RA/LA, the UE performs combined RA/LA update procedure when the target system operates in NMO I, or LA update 
procedure when the target system operates in NMO II/III. Also for NMO I if the UE performed only RA update due to 
the CS call the UE performs a combined RA/LA update (see TS 23.060 [3], clause 6.3.1) which creates the Gs 
association. 

7.4 Mobile Terminating call in Active IVIode - No PS HO support 
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Figure 7.4-1 : CS Page in E-UTRAN, Call in GERAN/UTRAN without PS HO 

la. The MSC receives an incoming voice call and responds by sending a Paging Request (IMSI or TMSI, optional 
Caller Line Identification and Connection Management information) to the MME over a SGs interface. The 
MSC only sends a CS Page for an UE that provides location update information using the SGs interface. In 
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active mode the MME has an established SI connection and if the MME did not return the "SMS-only" 
indication to the UE during Attach or Combined TA/LA Update procedures, the MME reuses the existing 
connection to relay the CS Service Notification to the UE. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the CS Page to the UE and sends CS Paging Reject towards MSC to stop 
CS Paging procedure, and this CSFB procedure stops. 

The eNB forwards the paging message to the UE. The message contains CN Domain indicator and, if received 
from the MSC, the Caller Line Identification. 

The MME immediately sends the SGs Service Request message to the MSC. containing an indication that the 
UE was in connected mode. The MSC uses this connected mode indication to start the Call Forwarding on No 
Reply timer for that UE and the MSC should send an indication of user alerting to the calling party. Receipt of 
the SGs Service Request message stops the MSC retransmitting the SGs interface Paging message. 

NOTE 1 : The pre -configured policy may be used by UE to avoid being disturbed without Caller Line Identification 
display and the detailed handling is to be decided by CT WGl and CT WG6. 

NOTE 2: This procedure can also take place immediately after MSC receives MAP_PRN from HSS, if pre-paging 
is deployed. Caller Line Identification is also provided in the case of pre-paging. 

lb. UE sends an Extended Service Request (CS Fallback Indicator, Reject or Accept) message to the MME. 
Extended Service Request message is encapsulated in RRC and Sl-AP messages. CS Fallback Indicator 
indicates MME to perform CS Fallback. The UE may decide to reject CSFB based on Caller Line Identification. 

Ic. Upon receiving the Extended Service Request (CSFB, Reject), the MME sends Paging Reject towards MSC to 
stop CS Paging procedure and this CSFB procedure stops. 

Id. The MME sends a Service Accept message encapsulated in an Sl-AP Request message that also includes the UE 
Radio Capabilities and a CS Fallback Indicator. This message: indicates to the eNB that the UE should be moved 
to UTRAN/GERAN. 

le. The eNB shall reply with Sl-AP Response message. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN cell to 
which the redirection procedure will be performed. 

3a. If the UE and network support inter-RAT cell change order to GERAN and the target cell is GERAN: The 
eNodeB triggers an inter-RAT cell change order (optionally with NACC) to a GERAN neighbour cell by 
sending an RRC message to the UE. The inter-RAT cell change order may contain a CS Fallback Indicator 
which indicates to UE that the cell change order is triggered due to a CS fallback request. If the inter-RAT cell 
change order contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, then 
the UE considers that CS fallback has failed. Service Request procedure is considered to be successfully 
completed when cell change order procedure is completed successfully. 

3b. If the UE or the network does not support inter-RAT handover from E-UTRAN to GERAN/UTRAN nor inter- 
RAT cell change order to GERAN: The eNodeB triggers RRC connection release with redirection to 
GERAN/UTRAN instead of PS HO or NACC. 

NOTE 3: Service Request procedure supervision timer shall be sufficiently long considering the optional 
measurement reporting at step 2. 

4. The eNodeB sends an S 1 UE Context Release Request (Cause) message to the MME. Cause indicates that the 
UE is not available for PS service. 

5. SI UE Context in the eNodeB is released as specified in TS 23.401 [2]. 

6. The UE moves to the new cell in GERAN/UTRAN, establishes a radio signalling connection. 

If the UE obtains LA information of the new cell (e.g. based on the system information) and the LA of the new 
cell is different from the one stored in the UE, it performs a Location Area Update or a Combined RA/LA 
Update procedure in case the target system operates in Network Mode of Operation (NMO) I. Alternatively, in 
NMO I, the UE in GERAN may perform LA update over the RR connection instead of combined RA/LA update 
over the packet access as defined in TS 24.008 [21], clause 4.7.5.2.5, unless enhanced CS establishment in DTM 
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is supported. If MSC is changed, the Roaming Retry for CSFB procedure as defined in clause 7.5 is triggered by 
Location Area Update or combined RA/LA update. 

If the UE moves to an UTRAN cell and ISR is not active or the RA of the cell is different to the one the UE is 
registered in, the UE performs a Routing Area Update. This can be performed as part of the combined RA/LA 
Update procedure when the LA of the new cell is different from the one stored in the UE and the target system 
operates in NMO I. 

7. If the target RAT is GERAN and DTM is not supported, the UE starts the Suspend procedure specified in 

TS 23.060 [3], clause 16.2.LL2. This triggers the SGSN to send a Suspend Request message to the MME. The 
MME returns a Suspend Response to the SGSN, which contains the MM and PDF contexts of the UE. 

8. If PS services are suspended, the MME starts the preservation of non-GBR bearers and the deactivation of GBR 
bearers. 

9. The UE responds to the paging by sending a Paging Response message as specified in TS 44.018 [4] or 
TS 25.331 [7]. When received at the BSS/RNS, the Paging Response is forwarded to the MSC. 

NOTE 4: The MSC should be prepared to receive a Paging Response after a relatively long time from when the CS 
Paging Request was sent (step la). 

9a. If the MSC that receives the Paging Response is different from the MSC that sent the Paging Request and if the 
Location Area Update / Combined RA/LA Update was not performed in step 6, the MSC shall reject the Paging 
Response by releasing the A/lu-cs connection. The BSS/RNS in turn releases the signalling connection for CS 
domain. 

9b. The signalling connection release shall trigger the UE to perform a Location Area Update as follows: 

If the target system operates in Network Mode of Operation (NMO) I and if the target system is UTRAN or the 
target system is GERAN supporting DTM and the UE supports DTM, the UE shall perform a combined RA/LA 
update, as defined in TS 23.060 [3]. 

If the target system operates in NMO II or III the UE performs a Location Area Update towards the MSC. 

The Location Area Update triggers the Roaming Retry for CS Fallback procedure as defined in clause 7.5. 

10. The CS Call Establishment procedure is initiated. 

With the exception of steps la and Ic, above. Call Forwarding (see TS 23.082 [31]) is performed on the basis of the 
TS 24.008 [21] signalling received on the GERAN/UTRAN cell. 

After the CS voice call is terminated and if the UE is still in GERAN and PS services are suspended, then (as specified 
in TS 23.060 [3]) the UE shall resume PS services by sending a Routing Area Update Request message to the SGSN. 
The Update Type depends on the mode of operation of the GERAN network, e.g. in mode I a Combined RA/LA Update 
is used and in mode II or III Routing Area Update is used. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21], i.e. if the UE is not registered in the current 
RA/LA, the UE performs combined RA/LA update procedure when the target system operates in NMO I, or separate 
LA update and RA update procedures when the target system operates in NMO II/III. Also for NMO I if the UE 
performed only RA update due to the CS call the UE performs a combined RA/LA update (see TS 23.060 [3], 
clause 6.3.1) which creates the Gs association. 



7.5 Roaming Retry for CS fallback 



The procedure in this section is applied for mobile terminated calls where the MSC, to which the UE sends the LAU, is 
different from the MSC that sent the paging message to the UE. The procedure is based on the 'Mobile Terminating 
Roaming Retry Call' procedure defined in TS 23.018 [5] and there is an only minor adaptation of the procedure to 
support CS fallback. 
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Figure 7.5-1 : Roaming Retry for CS fallback 

There are only 2 differences in this procedure compared to the 'Mobile Terminating Roaming Retry Call' procedure 
defined in TS 23.018 [5]. The first difference is that the paging message triggers the CS fallback including a location 
update in the new RAT. This functionality is already supported in the CS fallback flows for terminating calls and no 
additional functionality is needed. The second difference is that the UE may send a page response message after 
receiving Location Update Accept message. The new MSC will ignore or reject the page response message. 



7.6 Returning back to E-UTRAN 



Once CS service ends in CS domain, existing mechanisms can be used to move the UE to E-UTRAN, no specific CS 
Fallback mechanisms are needed. 

When the UE moves to E-UTRAN, if the EPS service was suspended during the CS service, it is resumed as specified 
in clause 6.5. 
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7.7 
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Figure 7.7.2-1 : Mobile Terminating Call when ISR is active and SGs is active between MSC/VLR and 

MME 

1) G-MSC receives lAM. 

2) G-MSC retrieves routing information of the terminating UE by Send Routing Info procedures as specified in 
TS 23.018 [5]. 

3) G-MSC sends lAM to the MSCA^LR on the terminating side as specified in TS 23.018 [5]. 

4) The MSCA^LR sends a Page message to the MME via SGs (details on the Page message can be found in 
clauses 7.2 or 7.3). 

5a) The MME receives the Page message from the MSCA^LR. If the UE is in ECM-IDLE state, the MME sends a 
Paging (as specified in TS 23.401 [2], and CN Domain Indicator) message to each eNodeB serving the TA list 
the UE is registered to as specified in clause 7.2. If the UE is in ECM -CONNECTED, the MME relays the CS 
Page message to the serving eNodeB over the SI interface as specified in clause 7.3. 

5b) The eNodeBs receive CS paging messages from the MME, and the procedures take place as specified in 

clause 7.2. 

6a As ISR is active and the UE is in ECMJDLE state, the MME forwards the CS paging message received from 
the MSCA^LR to the associated SGSN. The MME gets the SGSN information in the regular ISR activation 
process. 

6b)The SGSN receives the CS paging message from the MME, the SGSN sends paging messages to RNS/BSSs, 
which is described in detail in TS 23.060 [3]. 

The SGSN shall not implement a local retransmission scheme for the lu/Gb paging messages. 

6c) When RNS/BSS nodes receive paging message from the SGSN, paging is initiated as described in detail in 
TS 23.060 [3]. 

NOTE: If ISR is not active or the UE is in ECM-CONNECTED state, the MME does not send the CS paging 
message to the SGSN. That means, the steps of 6a, 6b, 6c are not needed in the MT call procedure. 
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7) Upon receipt of a Paging Request message for a circuit-switched service, the CS Fallback (as defined in this 
specification) or Cell Reselection (as defined in TS 23.060[3]) take place, and the UE accesses CS domain from 
UMTS/GSM. 

8) When the CS Fallback or Cell Reselection completes, the UE responds to the CS paging request and returns the 
CS paging response as described in detail in this specification and TS 23.060 [3] to the RNS/BSS. 

9) When received at the RNS/BSS, the CS Paging Response message is sent to the MSC/VLR as described in detail 
in TS 23.060 [3]. The MSC/VLR receives CS paging response contained in corresponding message which shall 
then stop the paging response timer and establish the CS connection, then the MT call process as described in 
detail in TS 23.018 [5]. 

7.7.3 Void 

7.8 Mobile Terminating Call when SGs is not active 

Regular pre-Release 8 MSC procedures are performed without any ISR or SGs specifics. 



8 Other CS Services 

8.1 General 

The MSC handles the timers, queuing and retransmission for sending the SGsAP-P AGING-REQUEST message on the 
SGs interface in the same way that it handles the sending of a PAGING message on the A or lu interface. As a 
consequence, the MME and (if ISR is active) the SGSN shall not implement local retransmission schemes for this 
paging. 

8.2 Short Message Service (SMS) 

8.2.1 General 

The procedures for SMS in this specification apply only if the UE is EPS/IMSI attached and the CS access domain is 
chosen by the UE and/or the home PLMN for delivering short messages. 

This clause describes both the mobile originating and mobile terminating SMS over SGs procedures in EPS. SMS 
support is based on the connectionless SGs reference point between the MME and the MSC Server and use of NAS 
signalling between the UE and the MME, i.e. no CS Fallback is performed for SMS. 

The SMS protocol entities are reused from the existing MS/UE and MSC implementations. This means that the SMS 
over SGs procedures reuse the different protocol layers as defined in TS 23.040 [14]. 

8.2.2 IVIobile originating SIVIS in Idle IVIode 

The following sequence flow shows the delivery of mobile originating SMS in idle mode. The message flows between 
the ME/UE and MSC/VLR are also broadly applicable to the Memory Available Notification. 
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Figure 8.2.2-1 : Mobile originating SMS in idle mode 

1. The combined EPS/IMSI attach procedure as described in clause 5.2 has been performed earher. 

2. A mobile originating SMS is triggered and the MS/UE is in idle mode. The MS/UE initiates the UE triggered 
Service Request procedure, which is defined in TS 23.401 [2]. The UE indicates its S-TMSI in the RRC 
signalling. 

3. The MS/UE builds the SMS message to be sent as defined in TS 23.040 [14] (i.e. the SMS message consists of 
CP-DATA/RP-DATA/TPDU/SMS-SUBMIT parts). Following the activation of the Radio Bearers, the SMS 
message is encapsulated in an NAS message and sent to the MME. 

4. The MME forwards the SMS message to the MSC/VLR in an Uplink Unitdata message. In order to permit the 
MSC to create an accurate charging record, the MME adds the IMEISV, the local time zone, the Mobile Station 
Classmark 2, and the UE's current TAI and E-CGI. 

4a. The MSC/VLR acknowledges receipt of the SMS to the UE. 

5.-8. These steps are performed as defined in TS 23.040 [14]. The SMS message is forwarded to the SC that 
returns a delivery report message. 

9. The MSC/VLR forwards the received delivery report to the MME associated with the MS/UE in a Downlink 
Unitdata message. 

10. The MME encapsulates the received delivery report in an NAS message and sends the message to the MS/UE. 

11. 12. The UE acknowledges receipt of the delivery report to the MSC/VLR. 

13. The MSC/VLR indicates to the MME that no more NAS messages need to be tunnelled. 

The MME should not use the SGs Release Request message as a trigger for the release of SI resources. 

NOTE: This is because the MME does not know whether the Service Request performed in step 2 was solely for 
the purpose of SMS, or, was for SMS and user plane data, or, whether or not the mobile has additional 
SMSs to send. 



ETSI 



3GPP TS 23.272 version 9.2.0 Release 9 



35 



ETSI TS 123 272 V9.2.0 (2010-01) 



8.2.3 Mobile originating SMS in Active Mode 

Mobile Originating SMS in active Mode procedure is specified by reusing the Mobile Originating SMS in Idle Mode 
with the following modification: 

The established signalling connection between the MS/UE and the MME is reused for the transport of the SMS 
message and the delivery report (i.e. the UE triggered Service Request procedure defined in step 2 is skipped). 

8.2.3a Multiple Mobile originating SMSs 

In clause 3.2 of TS 24.01 1 [28], the simultaneous transmission of more than one MO SMS/notification per domain is 
prohibited. 

If the UE has more than one SMS/notification to send, the subsequent SMS/notification is sent at step 11 of clause 8.2.2 
and the acknowledgement of the delivery report for the previous SMS/notification is not sent. 

8.2.4 Mobile terminating SMS in idle mode 

The following sequence flow shows the delivery of mobile terminating SMS in idle mode. 
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Figure 8.2.4-1 : Mobile terminating SMS in idle mode 

1. The combined EPS/IMSI attach procedure as described in clause 5.2 has been performed. 

2-4. The SC initiates transfer of mobile terminating SMS. The HLR is requested for routing number for SMS 
services and the SMS message is forwarded to the MSC/VLR where the MS/UE is CS attached. 

5. The MSC/VLR sends a Paging (IMSI, VLR TMSI, Location Information, SMS indicator) message to the MME. 

6. The MME initiates the paging procedure by sending the Paging (as specified in TS 23.401 [2]) message to each 
eNodeB with cells belonging to the tracking area(s) in which the UE is registered. The UE is paged with its 
S-TMSI. 

7. The MS/UE is paged by the eNodeB s. 

8. The UE sends a Service Request message to the MME. The UE indicates its S-TMSI in the RRC signalling. The 
MME sends the Sl-AP Initial Context Setup Request message to the eNodeB and the eNodeB establishes the 
Radio Bearers. 
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8a. The MME sends a Service Request message to the MSC. In order to permit the MSC to create an accurate 

charging record, the MME adds the IMEISV, the local time zone, the Mobile Station Classmark 2, and the UE's 
current TAI and E-CGI. 

9a. The MSCA^LR builds the SMS message to be sent as defined in TS 23.040 [14] (i.e. the SMS message consists 
of CP-DATA/RP-DATA/TPDU/SMS-DELIVER parts). The MSC/VLR forwards the SMS message to the MME 
in a Downlink Unitdata message. 

9b. The MME encapsulates the SMS message in a NAS message and sends the message to the MS/UE. 

9c, 9d. The MS/UE acknowledges receipt of the SMS message to the MSCA^LR. 

10. The MS/UE returns a delivery report as defined in TS 23.040 [14]. The delivery report is encapsulated in an 
NAS message and sent to the MME. 

1 1 . The MME forwards the delivery report to the MSC/VLR in an Uplink Unitdata message. 

12-13. These steps are performed as defined in TS 23.040 [14]. The delivery report is forwarded to the SC. 

14-15. In parallel to steps 12-13, the MSC/VLR acknowledges receipt of the delivery report to the MS/UE. 

16. The MSC/VLR indicates to the MME that no more NAS messages need to be tunnelled. 

The MME should not use the SGs Release Request message as a trigger for the release of SI resources. 

NOTE: Although the MME could use the RRC establishment cause (set to mt- Access) sent in the Sl-AP Initial 
UE Message in step 8 to deduce that the MS/UE sent the Service Request solely for receiving the SMS), 
the MME does not know whether the MT-SMS might cause the initiation of user plane traffic or an MO 
SMS. So, for simplicity of MME implementation, the normal eNodeB procedures should be used to 
initiate the release of SI resources. 

8.2.5 Mobile terminating SMS in Active Mode 

Mobile terminating SMS in Active Mode procedure is specified by reusing the Mobile Terminating SMS in Idle Mode 
with the following modification: 

There is no need for the MME to perform Paging of the MS/UE after step 5. MME continues with step 8a (i.e. 
steps 6 to 8 are skipped). The MME immediately sends a Downlink Unitdata to the UE. 

8.2.5a Multiple Mobile terminating SMSs 

In clause 3.2 of TS 24.01 1 [28], the simultaneous transmission of more than one MT SMS per domain is prohibited. 

If the MSC/VLR has more than one SMS to send, the subsequent SMS is sent in a Downlink Unitdata message after 
step 14 and instead of the Release Request in step 16 of clause 8.2.4. i.e. the MSC/VLR does not need to send another 
SGs Paging message. 

8.2.5b Simultaneous Mobile terminating and Mobile originating SMSs 

The above sections on mobile originating and mobile terminating SMS handling in active and idle mode can be reused 
such that no special treatment is needed for this case. 

8.2.5c Unsuccessful Mobile terminating SMS delivery attempt 

As specified in clause 3.2.8 of TS 23.040 [14], setting the Mobile Station Not Reachable Flag (MNRF) in the 
MSC/VLR is mandatory. However, when using the SGs interface, the MSC/VLR has delegated the 'implicit detach' 
functionality to the MME (and/or, if Network Mode of Operation 1 is in use in GERAN/UTRAN, to the SGSN). 

If an SGs based MT SMS delivery attempt fails, the MSC/VLR shall set its MNRF and send an SGs interface Alert 
Request message to the MME. Upon receipt of Alert Request message, MME shall set its Non-EPS Alert Flag (NEAF) 
and if ISR is activated, the MME shall then send an S3 interface Alert-MME-Request message to the SGSN. 
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Subsequently, if the UE makes radio contact with the SGSN, the SGSN informs the MME with an S3 interface UE- 
Activity-Indication. Upon receipt of the S3 interface UE- Activity-Indication, or, if the UE makes radio contact with the 
MME, the MME sends an SGs AP UE- Activity-Indication message to the MSC/VLR. 

Upon receipt of an SGs AP UE-Activity-Indication message, or signalling on the A, lu-cs or Gs interface for that UE, 
the MSC/VLR shall inform the HLR. 

8.2.5d Non-SMS Mobile terminating activity during SMS delivery 

While one or more SMS is being transferred, other mobile terminating requests (e.g. an MT voice call) may arrive in the 
MSCA'^LR. If this happens the MSC/VLR continues the SMS activities but shall also send the SGs Paging message for 
the non-SMS activity to the MME. The MME shall handle this SGs Paging message as if no SMS transfers are ongoing. 
Typically this should lead to the MME invoking the handover/call redirection to GERAN/UTRAN features and it may 
lead to disruption of the SMS delivery. The MSC/VLR and UE shall recover from any such SMS disruption using the 
normal RP and CP layer retransmission timers/mechanisms. 

8.2.5e Non-SMS Mobile originating activity during SMS delivery 

While one or more SMS is being transferred, other mobile originating requests (e.g. an MO voice call or USSD) may be 
requested by the user. If this happens the MS/UE continues the SMS activities but shall also send the Extended Service 
Request message for the non-SMS activity to the MME. The MME shall handle this Extended Service Request message 
as if no SMS transfers are ongoing. Typically this should lead to the MME invoking the handover/call redirection to 
GERAN/UTRAN features and it may lead to disruption of the SMS delivery. The MSC/VLR and UE shall recover from 
any such SMS disruption using the normal RP and CP layer retransmission timers/mechanisms. 

8.2.5f Mobile Terminating SMS when ISR is active and SGs is active 
between MSC/VLR and MME 

When the MME receives the SGs Paging message for SMS, and ISR is active, and the UE is in idle mode, the MME 
sends the SI interface paging message to the E-UTRAN (using the S-TMSI as temporary identity) and sends a CS 
paging message to the SGSN using the MSC TMSI as temporary identity (unless the MSC did not allocate a TMSI, in 
which case the IMSI is used for paging). 

The UE is paged on E-UTRAN and by the SGSN on GERAN and/or UTRAN. For GERAN, the SGSN sends a 
PAGING CS message to the BSS (see TS 48.018 [30]). For UTRAN, the SGSN sends a PAGING message to the 
UTRAN (see TS 25.413 [29]) with the CN Domain Indicator set to 'CS domain'. The UE responds on the cell on which 
it is camped. When camped on E-UTRAN, the UE responds to the MME. When camped on GERAN or UTRAN, the 
UE responds to the MSC. 

8.2.6 Co-Existence with SMS over generic 3GPP IP access 

If the home operator has deployed SMS over generic 3GPP IP access and/or SMS-Instant Messaging Interworking as 
defined in TS 23.204 [15], and has configured the network and the UE for using SMS over IP or SMS-Instant 
Messaging Interworking, then an SMS or IM will be delivered over EPS in any visited network whether or not the 
visited network supports SMS over generic 3GPP IP access. 

If the home operator has not deployed SMS over generic 3GPP IP access and the UE fails to successfully complete the 
combined EPS/IMSI attach procedure in the visited network (i.e. the visited network supports SMS over generic 3GPP 
IP access and does not support SGs for SMS capability), then the UE cannot execute MT or MO SMS procedures in the 
visited network. 

8.3 Location Services (LCS) 
8.3.1 MO-LR procedure 

MO-LR procedure in the CS fallback in EPS is performed as specified in TS 23.271 [8]. 
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When the MO-LR procedure is triggered by the UE's application, UE will check the LCS Support Indication provided 
by the Attach and TAU procedures as specified in TS 23.401 [2]: 

- If the LCS Support Indication indicates EPC -MO-LR is supported, and if the UE supports EPC-MO-LR, the UE 
stays in LTE and initiates the EPC-MO-LR procedure. 

Otherwise, if the LCS Support Indication indicates CS-MO-LR is supported, and the UE supports CS -MO-LR, 
the UE assumes CS-MO-LR is provided. 

Otherwise, the UE shall not attempt the EPC-MO-LR procedure. 

If the UE decided to initiate the CS Fallback for the LCS based on LCS Support Indication check, then, the following is 
applied: 

When UE is in active mode, UE and the network follows the procedure in clause 6.2 "Mobile Originating Call in 
Active-Mode". After UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs CS-MO-LR 
procedures as specified in TS 23.271 [8]. 

When UE is in active mode but there's no need for PS-Handover, then UE and the network follows the procedure 
in clause 6.3 "Mobile Originating Call in Active Mode - No PS HO Support in GERAN". After UE changes its 
RAT from E-UTRAN to UTRAN/GERAN, it performs CS-MO-LR procedure as specified in TS 23.271 [8]. 

When UE is in idle mode, UE follows the procedure in clause 6.4 "Mobile Originating Call in Idle Mode". After 
UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs CS-MO-LR procedure as specified in 

TS 23.271 [8]. 
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Figure 8.3.2-1 : MT-LR procedure 

1. MSC receives a PROVIDE_SUBSCRIBER_LOCATION message due to CS-MT-LR (TS 23.271 [8], 
clause 9.1.2). 

2. MSC sends Paging (LCS Client Identity, LCS indicator) message to MME. 

3. If the MME did not return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends Paging (parameters as specified in TS 23.401 [2], CN Domain Indicator, LCS Client 
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Identity, LCS indicator) message to UE. LCS indicator is used to inform the UE that this paging if for MT-LR 
request. LCS Client Identity and LCS indicator are only included in CS Page if UE is in active mode. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send Paging to the UE, and the MME sends CS Paging Reject towards MSC to 
stop CS Paging procedure and this CSFB procedure stops. 

4. UE responds with Paging_Resp message in UMTS/GERAN. Service based redirection/reselection or PS 
Handover may take place as specified in clause 7. 

5. MSC continues with the CS-MT-LR procedure as defined in TS 23.271 [8], clause 9.1.2. 

8.3.3 NI-LR procedure 

NI-LR procedure takes place during emergency calls, and is thus performed in GERAN/UTRAN during the Mobile 
Originating call procedure. 

8.3.4 Returning back to E-UTRAN 

Once CS service ends in CS domain, existing mechanisms as specified in TS 23.401 [2] can be used to move the UE to 
E-UTRAN, no specific CS Fallback mechanisms are needed. 

8.3.5 Co-Existence witin Otiner Location Services 
8.3.5.1 Co-Existence with SUPL 

There is no race condition between DMA AD SUPL [9] and CS Fallback for LCS. When network initiated SUPL 
procedure takes place, the paging message does not contain CN Domain Indicator by default. This prevents CS Fallback 
for LCS to take place. For SET initiated SUPL procedure, changing of RAT does not take place. 

8.4 Call Independent Supplementary Services 
8.4.1 Mobile-Initiated Call Independent SS procedure 

When UE is in active mode, UE and the network follow the procedure in clause 6.2 "Mobile Originating Call in 
Active-Mode". After UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs Mobile-Initiated Call 
Independent Supplementary Service procedure as specified in TS 24.010 [13]. 

When UE is in active mode and network initiates NACC procedure, then UE and the network follow the procedure in 
clause 6.3 "Mobile Originating Call in Active Mode - No PS HO Support in GERAN". After UE changes its RAT from 
E-UTRAN to UTRAN/GERAN, it performs Supplementary Service procedure as specified in TS 24.010 [13]. 

When UE is in idle mode, UE and the network follows the procedure in clause "Mobile Originating Call in Idle Mode". 
After UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs Supplementary Services procedure as 
specified in specifications such as TS 23.090 [10]. 
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8.4.2 NW-lnitiated Call Independent SS procedure 



MSC/VLR 



1 . Trigger 



2. Paging 



MME 



UE 



3. Paging 



4. Procedures Defined in Clause "Mobile Terminatina Call" 



5. Paging Response 



Call Independent Supplementary Services procedure continue 



Figure 8.4.2-1 : NW-lnitiated Call Independent Supplementary Service procedure 

1. MSC/VLR receives a trigger for NW-lnitiated Call Independent SS procedure. 

2. MSC/VLR sends Paging (optional Caller Line Identification, SS service ID) message to MME. 

3. If the MME did not return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends Paging (parameters as specified in TS 23.401 [2], CN Domain Indicator, optional 
Caller Line Identification, SS service ID) message to UE. SS service ID is used to indicate the type of the 
supplementary service (e.g. USSD) to the UE. Caller Line Identification and SS service ID are only included in 
CS Page if UE is in active mode. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the Paging to the UE, and the MME sends CS Paging Reject towards MSC 
to stop CS Paging procedure and this CSFB procedure stops. 

4. The mobile terminating call procedure then takes place as specified in clause 7 "Mobile Terminating Call 
Procedure". 

5. Once the paging is successfully returned to MSC, Supplementary Service procedures continues as specified in 
specifications such as TS 23.090 [10]. 

8.4.3 Returning back to E-UTRAN 

Once CS service ends in CS domain, existing mechanisms as specified in TS 23.401 [2] can be used to move the UE to 
E-UTRAN, no specific CS Fallback mechanisms are needed. 
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Annex A: 
Void 



£75/ 



3GPP TS 23.272 version 9.2.0 Release 9 42 ETSI TS 1 23 272 V9.2.0 (201 0-01 ) 



Annex B (normative): 
CS Fallback to 1xRTT 



This annex describes a CS Fallback to IxRTT and an SMS solution for dual mode IxRTT/E-UTRAN terminals. 

CS Fallback to IxRTT is supported for UEs with both single Rx and dual Rx configuration (see TS 36.331 [33]). UEs 
with single Rx configuration are not able to camp in IxRTT when they are active in E-UTRAN. The network therefore 
provides mechanisms for the UE to perform registration to IxRTT, receive IxRTT paging, SMS etc. while the UE is in 
E-UTRAN. UEs with dual Rx configuration can camp in IxRTT while they are active in E-UTRAN, they may however 
not be able to stay in E-UTRAN when they handle a CS call and/or perform registration signalling, and/or sending or 
receiving SMS in IxRTT. 

Clause B.l and B.2 describes the architecture and procedures for CS Fallback (and enhanced CS Fallback) to IxRTT 
when the UE has single Rx or dual Rx configuration. In this scenario the network need to support the SI 02 interface 
between the MME and IxCS system in order to support CS Fallback (this is indicated by the presence of CSFB 
registration parameters on E-UTRAN broadcast channel, TS 36.331 [33]). 

Clause B.3 describes the procedures for CS Fallback when the UE has dual Rx configuration. In this scenario the 
network needs to support the Extended Service Request procedure with CSFB indication in order to support CS 
Fallback (this is indicated by either the presence of CSFB registration parameters or indication of support for dual rx 
CSFB on E-UTRAN broadcast channel, TS 36.331 [33]). 

In case the UE has a dual Rx configuration it is up to the UE implementation to decide if it should follow the principles 
and procedures in clauses B.l and B.2, or the principles and procedures in clause B.3 when the network indicates 
support for S102. 



B.1 Overall Description 
B.1.1 General Considerations 

The CS fallback for IxRTT in EPS enables the delivery of CS-domain services (e.g. CS voice) by reuse of the IxCS 
infrastructure when the UE is served by E-UTRAN. A CS fallback enabled terminal, while connected to E-UTRAN 
may register in the Ix RTT CS domain in order to be able to use IxRTT access to establish one or more CS services in 
the CS domain. The CS Fallback function is only available where E-UTRAN coverage overlaps with IxRTT coverage. 

This specification also specifies the architecture required for SMS over SI 02 in EPS. The MO SMS and MT SMS are 
tunnelled in EPS and over SI 02 and do not cause any CS Fallback to CDMA IxRTT, and consequently does not require 
any overlapped CDMA IxRTT coverage. 

CS Fallback to IxRTT and IMS-based services shall be able to co-exist in the same operator's network. 

CS Fallback to IxRTT with PS Handover procedure to HRPD access for Optimised HO, non-Optimised HO, and 
Optimised Idle mode mobility as defined in TS 23.402 [27] shall be able to co-exist in the same operator's network. 

B.1 .2 Reference Architecture 

The CS fallback to IxRTT and SMS over S102 in EPS function is realised by reusing the S102 reference point between 
the MME and the IxCS IWS. The reference architecture described in figure B.l. 2-1 is similar to the SRVCC 
architecture for E-UTRAN to 3GPP2 IxCS described in TS 23.216 [20], with the additional aspect that the S102 
session is long-lived (similar to pre-registration for SlOl). 
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Figure B.I. 2-1 : Reference architecture for CS fallbacl< to IxRTT CS 

Reference architecture for PS handover procedure between E-UTRAN and HRPD access is defined in TS 23.402 [27]. 

B. 1 .2. 1 Reference points 

S102: It is the reference point between the MME and the IxCS IWS. The S102 reference point provides a tunnel 
between MME and 3GPP2 IxCS IWS to relay 3GPP2 IxCS signalling messages. Ix CS signalHng 
messages are those messages that are defined for A21 interface as described in 3GPP2 A.S0008-C [16] 
and3GPP2A.S0009[17]. 

B.1.3 Functional entities 
B.1.3.1 UE 

The UE capable of CS fallback to IxRTT and SMS over S102 supports access to E-UTRAN/EPC as well as access to 
the IxCS domain over IxRTT. It supports the following additional functions: 

IxRTT CS registration over the EPS after the UE has completed the E-UTRAN attachment; 

IxRTT CS re-registration due to mobility; 

CS fallback procedures specified for IxRTT CS domain voice service; 

Procedures for mobile originated and mobile terminated SMS tunnelled over EPS and S102; 

Includes enhanced CS fallback to IxRTT capability indication as part of the UE radio capabilities; 

Includes concurrent 1 xRTT and HRPD capability indication as part of the UE radio capabilities if supported by 
the enhanced CS fallback to IxRTT capable UE. 

B.1.3.2 IVIIVIE 

The MME enabled for CS fallback to IxRTT supports the following additional functions: 

It serves as a signalling tunnelling end point towards the 3GPP2 IxCS IWS via SI 02 interface for 
sending/receiving encapsulated 3GPP2 IxCS signalling messages to/from the UE, which are encapsulated in Sl- 
MME SI Information Transfer messages, as defined in TR 36.938 [19]; 
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IxCS-IWS (terminating S102 reference point) selection for CSFB procedures; 
Handling of S 102 tunnel redirection in case of MME relocation; 
Buffering of messages received via S 102 for UEs in idle state. 

B.1.3.3 E-UTRAN 

The E-UTRAN enabled for CS fallback to IxRTT supports the following additional functions: 

Provision of control information that causes the UE to trigger IxCS registration; 

Forwarding Ix RTT CS paging request to the UE; 

Forwarding Ix RTT CS related messages between MME and UE; 

Release of E-UTRAN resources after UE leaves E-UTRAN coverage subsequent to a page for CS fallback to 
IxRTT CS if PS handover procedure is not performed in conjunction with IxCS fallback; 

Invoking the optimised or non-optimised PS handover procedure concurrently with enhanced IxCS fallback 
procedure when supported by the network and UE, and based on network configuration. 

B.1 .4 Co-existence with IIVIS services 

Clause 4.4 of this specification also applies here. 

B.2 Procedures 

B.2.1 IVIobility IVIanagement 

B.2.1 .1 1x RTT CS Pre-Registration over EPS Procedure 

This clause describes how the UE in an E-UTRAN system establishes and maintains pre -registration in the IxCS 

system. 
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Figure B.2. 1.1-1: IxRTT CS registration procedure 

1. The UE attaches to E-UTRAN as specified in TS 23.401 [2]. The UE includes an indication of enhanced CS 
fallback to IxRTT and may also include concurrent IxRTT and HRPD PS session handling capabilities as part 
of the UE radio capabilities. 

2. Based on a radio layer trigger (e.g. an indication from the E-UTRAN when the UE is in connected state or an 
indication over the broadcast channel), the UE decides to register with the IxRTT CS domain. 

3. If the UE is in idle state, in order to create a signalling connection with the MME, it performs the Service 
Request procedure. 

4. The UE generates a IxRTT CS registration request. 

4a. The IxRTT CS message is transferred from the UE to E-UTRAN. 

4b. E-UTRAN forwards the IxRTT CS message to the MME including the CDMA2000 Reference Cell ID. 

4c. The MME selects a IxCS IWS node based on the CDMA2000 Reference Cell ID. The IMSI is used to 

distinguish S102 signalling transactions belonging to different UEs. The MME sends a S102 Direct Transfer 
message (IMSI, IxCS message) to the IxCS IWS node. 

5. IxRTT CS registration is then performed by the IxCS IWS node based on 3GPP2 A.S0008 [16]. 

6a. IxRTT CS registration response is tunnelled back to the MME in a S102 Direct Transfer message (IMSI, IxCS 
message). 

6b. The MME forwards the IxRTT CS message to the E-UTRAN. 

6c. The E-UTRAN forwards the IxRTT CS message to the UE. 

If the triggers for IxCS registration change over time, the UE (both in idle or connected state), uses this information to 
update the IxCS registration via the tunnel. 
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B.2.1 .2 S1 02 Tunnel Redirection 

SI 02 Tunnel Redirection Procedure is used when the UE perform Tracking Area Update with MME change while the 
UE is registered with the IxRTT CS domain as described in clause B.2.1.1 and the S102 session exists between the 
MME and the IxCS IWS. 

The detail procedure for the idle case is depicted as figure B.2.1. 2-1. 
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Figure B.2.1 .2-1: SI 02 tunnel redirection during TAU with MME change 

1. UE performs Ix-registration over the source MME while in ECM-CONNECTED state, followed by transition to 
ECM-IDLE state. The SI 02 tunnel exists between the source MME and the IxCS IWS. 

2. TAU procedure with MME change as described in TS 23.401 [4], figure 5.3.3.1-1, prior to the step where the 
target MME receives Update Location Ack from the HSS, is executed. The IxCS IWS ID is transferred to the 
target MME via the Context Response message. 

3. The target MME sends S102 Redirection Command message to the IxCS IWS. After receiving this message, the 
IxCS IWS associates the SI 02 tunnel for this specific UE with the target MME. Then the IxCS IWS releases 
any context associated with the source MME. 

4. In response to the S102 Redirection Command message, the IxCS IWS sends a S102 Redirection Ack message 
to the target MME. 

5. The TAU procedure is completed. 

The detailed procedure for the active case is depicted as figure B.2.1. 2-2. 
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Figure B.2.1. 2-2: S102 tunnel redirection during inter-eNodeB handover with MME relocation 

1. UE performs Ix-registration over the source MME while in ECM-CONNECTED state. The S102 tunnel exists 
between the source MME and the IxCS IWS. 
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2. Inter-eNodeB handover with MME relocation procedure as described in TS 23.401 [4], figure 5.5.1.2.2-1, steps 
prior to TAU, is executed. The IxCS IWS ID is transferred to the target MME via the Forward Relocation 
Request message. 

3. The target MME sends S102 Redirection Command message to the IxCS IWS. After receiving this message, the 
IxCS IWS associates the S102 tunnel with the target MME. Then the IxCS IWS releases any context associated 
with the source MME. 

4. In response to the SI 02 Redirection Command message, the IxCS IWS sends a S102 Redirection Ack message 
to the target MME. 

5. The TAU procedure occurs. 

B.2.1 .3 UE-initiated Detach Procedure 

If a IxRTT CS Fallback UE, pre-registered to the IxRTT CS system, initiates the detach procedure in E-UTRAN access 
due to switch off and the UE is required to perform a "power-down registration" in the IxRTT CS system (see 
C.S0005-A [32]), the UE shall first perform the "power-down registration" procedure with the IxRTT CS system via 
the SI 02 tunnel, before initiating the detach procedure in E-UTRAN access as specified in TS 23.401 [2]. 

A IxCSF UE, pre-registered to the IxCS system, performing detach due to reasons other than switch off is not required 
to perform "power-down registration" with the IxCS system prior to performing the detach procedure in E-UTRAN. 

B.2.2 Mobile Originating Call in Active IVIode 

This clause describes the mobile originating call procedures for the CS Fallback to IxRTT. For enhanced CS fallback to 
IxRTT procedure, see clause B.2.3a. 
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Figure B.2.2-1 : CS MO call using fallback to CDMA 1x RTT network 

1. UE is E-UTRAN attached and registered with IxRTT CS as defined in clause B.2.1.1. 

2. UE makes a decision to perform a mobile originated CS call. 

3. UE sends an Extended Service Request (CS Fallback Indicator) to the MME. 

4. MME sends a Sl-AP message that includes: a CS Fallback Indicator to indicate the E-UTRAN to move the UE 
to IxRTT. 

5. E-UTRAN may optionally solicit a IxRTT measurement report from the UE to determine the target IxRTT cell 
to which the CS Fallback will be performed. 

6a. The E-UTRAN triggers RRC connection release with redirection to IxCS and continue with step 7. 

7. E-UTRAN sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates that the SI 
UE Context Release was caused by CS fallback to IxRTT. 

8. MME sets the UE context to suspended status and sends to the S-GW a Suspend Request (IMSI) message that 
requests the suspension of EPS bearers for the UE. The Sl-U bearers are released for all EPS bearers by the 
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MME and all GBR bearers are deactivated. The non-GBR bearers are preserved and are marked as suspended in 
the S-GW. 

9. S-GW acknowledges the Suspend Request message and marks the UE as suspended. When a downlink data 
arrives at the S-GW, the S-GW should not send a downlink data notification message to the MME if the UE is 
marked as suspended. 

10. SI UE Context in the E-UTRAN is released as specified in TS 23.401 [2]. 

11. UE moves to IxRTT and performs the procedure for mobile originating call as specified in 
3GPP2A.S0013[18]. 

Once CS service ends in the IxCS domain, the UE returns to E-UTRAN by performing reselection. The EPS service is 
resumed as described in clause 6.5. 

B.2.2a Mobile Originating call in Idle Mode 

Mobile Originating call in Idle Mode procedure is specified by reusing the Mobile Originating Call in Active mode 
procedure with Extended Service Request (CS Fallback Indicator) to the MME. UE is transited to ECM- 
CONNECTED mode by following the applicable procedures specified in TS 23.401 [2]. 



B.2.3 Mobile Terminating Call 



This clause describes the mobile terminating call procedures when the UE accepts or rejects CS paging for the CS 
Fallback to IxRTT. 

When the Ix MSC receives a registration from a UE, it makes note of the RAN equipment from which it received the 
registration. Subsequent paging activities may thus be directed toward that RAN equipment. However, paging activities 
by the IxMSC are not limited to the single RAN equipment from which the registration was received. The MSC may 
choose to page a wider area, including inter-system paging. If the IxMSC has direct interfaces to IxCS IWS, as well as 
to IxRTT access, the MSC may choose to do direct paging activities to both E-UTRAN and Ix RAN equipments in its 
attempts to contact the UE. 

The Ix paging request sent by the IxMSC to the IxCS IWS is delivered to the UE via the tunnel. The UE tunes to 
IxRTT access, acknowledges the Ix page and performs the IxCS procedures for mobile terminated call. When the UE 
receives a page message, it may not want to accept it based on Caller Line Identification or pre-provisioned local policy. 
In that case, the UE sends the Ix Release Order to IxCS IWS over a tunnel in E-UTRAN and EPC. 

The detailed procedure using RRC connection release with redirection to IxCS is described in figure B.2.3-1. For 
enhanced IxRTT CS Fall Back procedure, see clause B.2.3a. 
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Figure B.2.3-1 : CS MT call using fallback to CDMA 1x RTT network 

1. UE is E-UTRAN attached and pre-registered with IxRTT CS as defined in clause B.2.1.1. 

2. IxMSC sends a paging request to the IxCS IWS node with Caller Line Identification if available. 

3. IxCS IWS node forwards the Ix RTT CS paging request with Caller Line Identification if available via the SI 02 
tunnel to the MME. 

4. If the UE is in idle state, the MME performs the network initiated Service Request procedure in order to bring 
the UE to active state prior to tunnelling of the Ix RTT CS paging request toward the UE. 

5. MME forwards the IxRTT CS paging request to the UE. 

6a. If the UE decides to reject CSFB based on e.g. user decision by Caller Line Identification or UE locally pre- 
provisioned policy, then the UE rejects the Ix CS paging by sending an Ix Release Order to the MME. The 
MME forwards the Ix Release Order in an S102 Direct Transfer message to the IxCS IWS and the Ix IWS 
sends a Rejection to the Ix MSC. This completes the procedure. 
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6b. If the UE accepts CS paging for the CS Fallback to IxRTT, the UE sends an Extended Service Request (CS 
Fallback Indicator) to the MME and proceeds with step 7 to step 15 below. 

7. MME sends Sl-AP: UE Context Modification (CS Fallback Indicator) to indicate the E-UTRAN to move the UE 
to IxRTT. 

8. E-UTRAN may optionally solicit a IxRTT measurement report from the UE to determine the target IxRTT cell 
to which the CS Fallback will be performed. 

9. E-UTRAN triggers RRC connection release with redirection to IxCS. 

10. E-UTRAN sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates that the SI 
UE Context Release was caused by CS fallback to IxRTT. 

1 1. MME sets the UE context to suspended status and sends to the S-GW a Suspend Request (IMSI) message that 
requests the suspension of EPS bearers for the UE. The Sl-U bearers are released for all EPS bearers by the 
MME and all GBR bearers are deactivated. The non-GBR bearers are preserved and are marked as suspended in 
the S-GW. 

12. S-GW acknowledges the Suspend Request message and marks the UE as suspended. When a downlink data 
arrives at the S-GW, the S-GW should not send a downlink data notification message to the MME if the UE is 
marked as suspended. 

13. SI UE Context in the E-UTRAN is released as specified in TS 23.401 [2]. 

14. UE tunes to IxRTT and acknowledges the page by transmitting a IxRTT Paging Response message over the Ix 
Access Channel. 

15. Subsequently UE performs the procedure for mobile terminated call establishment as specified in 3GPP2 
A.S0013 [18]. 

Once CS service ends in the IxCS domain the UE returns to E-UTRAN by performing reselection. The EPS service is 
resumed as described in clause 6.5. 

B.2.3a Enhanced CS fallback to IxRTT Procedure 

B.2.3a.1 General 

Enhanced CS fallback to IxRTT procedure may be used when the UE indicates its support of this capability to the 
network. If in addition, the UE also indicates its support of concurrent IxRTT and HRPD PS session handling, this 
indication also allows the network to invoke optimised or non-optimised PS handover procedure concurrently with the 
enhanced CS fallback to IxRTT procedure. 

If enhanced CS fallback to IxRTT procedure is not used by the network (i.e., not supported or not configured), the 
network uses RRC connection release with redirection as specified in clauses B.2.2 and B.2.3. 

NOTE 1 . Other 3GPP2 specific procedure (e.g. how UE performs concurrent operation in 3GPP2 network) is 
outside the scope of this specification. 

NOTE 2. E-UTRAN may invoke concurrent optimised active-mode PS handover procedure or non-optimised PS 
handover procedure when it receives Sl-AP: UE Context Modification with CSFB indication, based on 
UE capability and operator configuration. 

B.2.3a.2 Mobile Originating Call without concurrent PS handover, or with concurrent 
non-optimised PS handover or optimised idle-mode PS handover 

The following figure describes the mobile originating call procedures for the enhanced CS Fallback to IxRTT with 
concurrent non-optimised PS handover or optimised idle-mode PS handover, or without concurrent PS handover. 
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Figure B.2.3a.2-1 : Enhanced CS fallback to 1xRTT MO Call with no PS handover, or with concurrent 
non-optimised PS handover or optimised idle-mode PS handover 

1. UE is E UTRAN attached and registered with IxRTT CS as defined in clause B.2.1.1 with enhanced CS fallback 
to IxRTT capability indication to the network. The UE may also indicate that it supports concurrent IxRTT and 
HRPD capability.. The UE may also be pre -registered with HRPD access using procedures defined in TS 23 

402 [27], clause 9.3.1. 

2. UE makes a decision to perform a mobile originated CS call. 

3. UE sends an Extended Service Request (CS Fallback Indicator) to the MME. 

4. MME sends a S 1 -AP message that includes: a CS Fallback Indicator to indicate the E UTRAN to move the UE 
to IxRTT. 

5. E-UTRAN may optionally solicit a IxRTT measurement report from the UE to determine the target IxRTT cell 
to which the CS Fallback will be performed. 

If the network supports PS handover procedure to HRPD then E-UTRAN may optionally solicit an HRPD 
measurement report from the UE to determine whether the target HRPD candidates exist or not. If the network 
does not support PS handover procedure to HRPD or if no target HRPD candidates exist then E-UTRAN shall 
release the SI UE context (see step lOa/b) after executing the enhanced CS fallback to IxRTT procedure. 



£75/ 



3GPP TS 23.272 version 9.2.0 Release 9 53 ETSI TS 1 23 272 V9.2.0 (201 0-01 ) 

6. E-UTRAN sends a HandoverFromE-UTRAPreparation Request message to the UE to start the enhanced IxCS 
fallback procedure. It includes 3Glx Overhead Parameters and RAND value. This message also includes an 
indication that concurrent HRPD handover preparation is not required. 

7. The UE initiates signalling for establishment of the CS access leg by sending UL HandoverPreparation Transfer 
message which contains the IxRTT Origination message with called party number. 

8. Messages between MME and IxIWS are tunnelled using the S102 interface. The IxRTT MSC initiates the call 
with the called party number carried in the IxRTT Origination message. 

9. The E UTRAN sends Mobility from EUTRA Command to the UE with indication that this is for enhanced Ix 
CS Fallback operation, IxRTT related information, and optionally the HRPD redirection information. The 
IxRTT information contains IxRTT messages related to Ix channel assignment and cause the UE to tune to and 
acquire this Ix channel. This is perceived by the UE as a Handover Command message to IxRTT. If IxRTT CS 
network cannot support this CSFB request (for example due to resource availability), the DL information 
transfer message is sent instead, with an embedded Ix message that indicates failure to the UE. 

For either concurrent non-optimised PS handover procedure or optimised idle-mode PS handover procedure 
along with enhanced CS fallback to IxRTT, E-UTRAN may also redirect the UE to HRPD as part of this 
procedure. This is indicated by the HRPD redirection information in the Mobility from EUTRA Command. 

lOa/b. If PS handover procedure is not performed then E-UTRAN sends an SI UE Context Release Request (Cause) 
message to the MME. Cause indicates that the SI UE Context Release was caused by CS fallback to IxRTT. 
MME sets the UE context to suspended status and sends to the S-GW a Suspend Request (IMSI) message that 
requests the suspension of EPS bearers for the UE. The Sl-U bearers are released for all EPS bearers by the 
MME and all GBR bearers are deactivated. The non-GBR bearers are preserved and are marked as suspended in 
the S-GW. 

1 1. UE retunes to the IxRTT radio access network and performs Ixchannel acquisition with the IxRTT CS access 
(e.g. IxRTT BSS). 

12. UE and Network follow the appropriate procedure for handling non-optimised PS handover procedure or 

optimised idle-mode PS handover as defined in TS 23.402 [27] if performed. SI UE Context release procedure is 
as specified in TS 23.402 [27] for non-optimised PS handover (clause 8.2.2) or optimised idle-mode PS 
handover (clause 9.4). This step occurs in parallel with step 11. 

B.2.3a.3 Mobile Originating Call with concurrent optimised PS handover 

The following figure describes the mobile originating call procedures for the enhanced CS Fallback procedure to 
IxRTT with concurrent optimised PS handover. 
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Step 1-5, same as in igure B. 2. 3a. 2-1 



6. HOfromEUTRAPrep. Request 

(3G1x parameter, RAND, con-HRPD HO indication) 



_7a. ULHOprepXfer_ 
(MEiD, 1x Message) 



_7b. UL HO prepXfer_ 
(HRPD) 



8a. UL S1 cclma2000 tunneiing 
(IxCSFB) 



8b. UL S1 cdma2000 tunneiing 
(HRPD) 



1xCS 
IWS 



1xRTT 
MSC 



9a. SI 02 Direct Transfer, and IxMSC interworking 



9b. SI 01 Direct 

Transfer with 

HRPD access 

node. 



10a. DL S1 cdma2000 tunneiing 
(IxCSFB) 




11. MobiiityFromEUTRA (elxCSFB incl,1xRTT parameters, Inrpd HO info) 



12. UE tunes to IxRTTand resumes with 3GPP2 specific procedure. 



HRPD 



13. HRPD PS HO as 
per TS 23.402. 



Figure B.2.3a.3-1 : Enhanced CS fallback to 1xRTT MO Call with concurrent optimised PS handover 

1-5. Same as steps 1-5 in figure B.2.3a.2-1. The UE indicates that it supports enhanced CS fallback to IxRTT 
procedure and concurrent IxRTT and HRPD capability. 

6. E-UTRAN sends an Handover From E-UTRA Preparation Request message to the UE to start the enhanced 
IxCS fallback procedure. It includes 3Glx Overhead Parameters and RAND value. This message also includes 
an indication that concurrent HRPD handover preparation is required. 

7. UE starts the enhanced IxCS fallback and optimised PS handover messages (7a, 7b) in a sequential manner. Step 
7a contains the IxRTT Origination message with called party number. 

8a, 9a, 10a, and 8b, 9b, 10b. 

MME treats the enhanced IxCS fallback and HRPD PS handover procedure independently (i.e. MME does not 
link the HRPD message and IxCS fallback message together). 

8a, 9a, 10a is same as shown in step 8 in figure B. 2. 3a. 2-1 

8b, 9b, 10b are messages/procedure for optimised E-UTRAN to HRPD handover procedure as defined in 

TS 23.402 [27], clause 9.3.2. 
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11. The E-UTRAN sends Mobility from EUTRA Command to the UE with indication that this is for enhanced Ix 
CS Fallback operation including the IxRTT message and the HRPD message received over the S102 and SlOl 
tunnels. 

If handover preparation to HRPD is successful but preparation failure message in received from the IxRTT CS 
network via the SI 02 tunnel, the message for IxRTT preparation failure indication is sent to the UE as part of 
the Mobility from EUTRA Command. If handover to HRPD is successful and the eNB times out waiting for 
preparation completion message from IxRTT, the E-UTRAN sends a Mobility from EUTRA command with 
only the HPRD message included. In the case that the preparation to HRPD failed but IxRTT is successful, 
E-UTRAN may optionally include HRPD redirection info as part of the Mobility from EUTRA Command. 

In case preparation on IxRTT and HRPD failed with explicit failure messages received on S102 and SOI 
tunnels, the E-UTRAN forwards the received failure messages as DL Information transfers 

12. UE retunes to the IxRTT radio access network and performs Ix channel acquisition with the IxRTT CS access 
(e.g. IxRTT BSS), see TS 23.216 [20], clause 6.1.3. 

13. UE and network follow the optimised E-UTRAN to HRPD handover procedure. UE context release procedure 
follows the optimised E-UTRAN to HRPD handover procedure as defined in TS 23.402 [27], clause 9.3.2. This 
step occurs in parallel with step 12. 

B.2.3a.4 Mobile Terminating Call without PS handover, or with concurrent non- 
optimised PS handover or optimised idle-mode PS handover 

The following figure describes the mobile terminating call procedures for the enhanced CS Fallback to IxRTT with 
concurrent non-optimised PS handover or optimised idle-mode PS handover, or without PS handover. 
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Step 2-7, same as in Figure Figure B.2.3-1. 



8. Optional measurement report i 
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1-^ 

9. HOfromEUTRAPrep. Request 

(3G1x parameter, RAND, con-HRPD HO indication) 



10. UL HO prepXfer 
(IVIEID, IxPageResponse) 



1 1 . UL S1 cdma2000 tunneling 
(...) 



12. S102 Direct Transfer, and 1xMSC interworl<ing 
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13. DL SI cdma2000 tunneling 
(...) 

-I 



14. IVIobiiityFromEUTRA (elxCSFB ind,1xRTT parameters, hrpd redirection info) 

I 
15a. SI UE context Release Request 



ISb.Suspend Reqeust/Acl< 



16. UE tunes to IxRTT and resumes with 3GPP2 specific procedure. 



HRPD 



X 



I 17. HRPD PS HO as 



per TS 23.402. 



Figure B.2.3a.4-1 : Enhanced CS fallback to IxRTT MT call without PS handover, or with concurrent 
non-optimised PS handover or optimised idle-mode PS handover 

1. UE is E-UTRAN attached and pre-registered with IxRTT CS as defined in clause B.2.1.1 with enhanced CS 
fallback to IxRTT capability indication to the network. The UE may also indicate that it supports concurrent 
IxRTT and HRPD capability The UE may also be pre-register with HRPD access using procedures defined in 

TS 23.402 [27], clause 9.3.1. 

2-7. Same as step 2-7 in figure B.2.3-1. 

8-17. Same as steps 5-12 of Figure B.2.3a.2-1, with the only modification that the Ix message in step 7 of Figure 
B.2.3a.2-1 provided by the UE to the E-UTRAN is a IxPage Response message. 

B.2.3a.5 Mobile Terminating Call with concurrent optimised PS handover 

The following figure describes the mobile terminating call procedures for the enhanced CS Fallback to IxRTT with 
concurrent optimised PS handover. 
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Step 1-8, same as in figure B. 2. 3a. 4-1 



9 HOfromEUTRAPrep. Request 

(3G1x parameter, RAND, con-HRPD HO indication) 



10 



10a. IxCSFB info 
(MEiD, IxPage Response) 



-10b. UL HO Prep (HRPD)- 
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(IxCSFB) 



12a. SI 02 Direct Transfer, and IxMSC interworking 



11b. ULS1 cdma2000 tunneiing 
(HRPD) 
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Direct Transfer 

with HRPD 
access node. 



13a. DL SI cdma2000 tunneiing 
(IxCSFB) 



13b. DL SI cdma2000 tunneiing 
(HRPD) 



14. MobiiityFromEUTRA (elxCSFB ind,1xRTT parameters, hrpd HO info) 



1 5. UE tunes to IxRTT and resumes with 3GPP2 specific procedure. 



HRPD 



16. HRPD PS HO as 
per TS 23.402. 



Figure B.2.3a.5-1 : Enhanced CS fallback to 1xRTT MT Call with concurrent optimised PS handover 

1-8. Same as steps 1-8 in figure B.2.3a.4-1. The UE indicates that it supports enhanced CS fallback to IxRTT 
procedures and concurrent IxRTT and HRPD capability. The UE may also be pre-register with HRPD access 
using procedures defined in TS 23.402 [27], clause 9.3.1. 

9-16. Same as steps 6-13 of Figure B.2.3a.3-1, with the only modification that the Ix message in step 7 of 
Figure B.2.3a.2-1 provided by the UE to the E-UTRAN is a IxPage Response message. 

B.2.3a.6 Interaction between enhanced CS Fallback to IxRTT and optimised PS 
handover 

For regular optimized PS handover procedure, it is possible that the UE receives IxRTT CS paging from EPS while 
optimised PS handover to HRPD is in progress. In this case, UE shall ignore the IxRTT CS paging locally. 

B.2.4 Short Message Service (SMS) 
B. 2.4.1 General 

The procedures for SMS in this annex apply only if the UE is IxRTT CS Registered and the CS access domain is 
chosen by the UE and/or the home PLMN for delivering short messages. 

This clause describes both the mobile originating and mobile terminating SMS over SI 02 which uses IxCS procedures 
in EPS. SMS support is based on the S102 reference point between the MME and the IxCS IWS, use of RRC 
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Information Transfer message between the UE and the E-UTRAN, and use of SI cdma2000 Tunnelling message 
between the E-UTRAN and the MME. 



B. 2.4.2 Mobile originating SMS 



The following sequence flow shows the delivery of mobile originating SMS sent via the IxMSC while in E-UTRAN. 
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Figure B.2.4.2-1 : Mobile originating SIVIS sent via the IxlVISC while in E-UTRAN 

1. The IxRTT CS Registration procedure as described in clause B.2.1.1 has been performed earlier. 

2. A mobile originating short message is triggered. If the UE is in idle state, the UE performs the UE triggered 
Service Request procedure, which is defined in TS 23.401 [2]. 

3. The UE builds the SMS message to be sent as defined in 3GPP2 A.S0008 [16] and 3GPP2 A.S0009 [17]. 
3a. The IxRTT SMS message is transferred from the UE to the E-UTRAN. 

3b. The E-UTRAN forwards the SMS message to the MME. 

4. The MME forwards the SMS message to the IxCS IWS in an S102 Direct Transfer message. 

5. The IxCS IWS acknowledges the message. 
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6. The IxCS IWS sends an ADDS Transfer message to the IxMSC containing the SMS message as defined in 
3GPP2 A.S0008 [16] and 3GPP2 A.S0009 [17]. 

7. The IxMSC forwards the SMS message to the Message Centre (MC). If an acknowledgement was requested by 
the UE, the MC responds with an acknowledgement. 

8. The IxMSC forwards the SMS acknowledgement to the IxCS IWS in an ADDS Page message. 

9. The IxCS IWS forwards the SMS acknowledgement to the MME in an S102 Direct Transfer message. 

10. The MME forwards the SMS acknowledgement to the UE. 

11. The MME sends an SI 02 Ack message to the IxCS IWS. This occurs immediately after step 9 if the MSC has 
not requested an acknowledgement from the IxCS IWS. 

12. If the MSC requested an acknowledgement, the IxCS IWS sends an ADDS Page Ack message to the IxMSC. 

B.2.4.3 Mobile terminating SMS 

The following sequence flow shows the delivery of mobile terminating SMS sent via the IxMSC while in E-UTRAN. 



lxCS 

CSFB 

UE 



I 



E- 
UTRAN 



I 



MME 



_L 



1xCS 
IWS 



T 



1xRTT 
MSC 



I 



1. UE is E-UTRAN attached and registered with 1xRTT CS 



3. 1xRTT Air Interface Sign< 



S1 02 Direct Transfei 



4. If UE is idle, MME performs Network-initiated 
service request 



5. IxRTTAir Irterface Signaling 



5b. UiyOL Information 
Transfer 



8. IxRTTAir Irterface Signaling 



8a. UL/DL Information 
Transfer 



5a. UUDL S1 cdma2000 
Tunnelling 



8b. UL/DL S1 cdma2000 
Tunnelling 



6. Ack 



S1 02 Direct Transfer 



9. IxRTTAir Interface Sign; 



S1 02 Direct Transfe 
10. Ack 



S1 02 Direct Transfer 



2. ADDS Page 



ling 



7. ADDS Page Ack 



ling 



1 1 . ADDS Transfer 



Figure B.2.4.3-1 : Mobile terminating SIVIS sent via the IxlVISC while in E-UTRAN 

1. The UE is E-UTRAN attached and registered with IxRTT CS as defined in clause B.2.1.1. 

2. The IxMSC receives the SMS message from the MC and sends an ADDS Page message to the IxCS as defined 
in 3GPP2 A.S0008 [16] and 3GPP2 A.S0009 [17]. The ADDS Page contains the SMS message. 

3. The IxCS IWS sends the SMS message in an S102 Direct Transfer message. 

4. If the UE is in idle state, the MME performs the network initiated Service Request procedure to bring the UE to 
active state prior to tunnelling of the SMS message toward the UE. 
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5. The MME forwards the SMS message to the UE. 

6. The MME sends an S102 Ack message to the IxCS IWS. This occurs immediately after step 3 if the MSC has 
not requested an acknowledgement from the IxCS IWS. 

7. If the MSC requested an acknowledgement, the IxCS IWS sends an ADDS Page Ack message to the IxMSC. 

8. After receiving the SMS message at step 5, the UE sends an SMS acknowledgement toward the MC. 

9. The MME forwards the SMS acknowledgement in an S102 Direct Transfer message to the IxCS IWS. 

10. The IxCS IWS sends an SI 02 Ack message to the MME. 

11. The IxCS IWS forwards the SMS acknowledgement to the IxMSC. The IxMSC then forwards the SMS 
acknowledgement to the MC. 



B.2.5 Emergency Calls 



When UE is performing CS fallback procedure to IxRTT for the purpose of emergency call, it shall indicate to the 
MME that this CS fallback request is for emergency purpose. MME also indicates to the E-UTRAN via the appropriate 
S 1-AP message that this CS fallback procedure is for emergency purpose. 

Emergency call with enhanced IxRTT CS fallback procedure shall be executed without the concurrent PS handover 
procedure. 



B.3 CS Fallback for UEs with dual Rx configuration 
B.3.1 General Considerations 

The following principles are used for supporting CS Fallback for dual receiver UEs: 

The UE with dual Rx configuration attaches separately to each RAT (E-UTRAN, IxRTT) and maintains 
separate registration and mobility procedure handling to each RAT. No coordination is required between the 
E-UTRAN and IxRTT network. 

The UE with dual Rx configuration is able to camp in IxRTT at the same time as it is active or idle in 
E-UTRAN. Camping in IxRTT includes performing IxRTT cell re-selection, reading broadcast channels, 
monitoring paging, performing location updates, etc. according to 3GPP2 specifications. 

The UE with dual Rx configuration is allowed to leave E-UTRAN in order to handle a CS call and/or perform 
registration signalling, and/or sending or receiving SMS in IxRTT. The procedures for leaving E-UTRAN is 
described in clause B.3. 2 and are only allowed if the network indicates that it supports them (this is indicated by 
either the presence of CSFB registration parameters or indication of support for dual Rx CSFB on E-UTRAN 
broadcast channel, TS 36.331 [33]). 

The UE that reports dual Rx configuration to E-UTRAN does not require redirection information. 

The UE with dual Rx configuration which intends to use the procedures described in clause B.3 should not 
indicate to the network that it support enhanced CS fallback to IxRTT capability in the UE radio capabilities. 

NOTE 1 : The last principle is required in order to avoid compatibility issues with network supporting enhanced CS 
Fallback to IxRTT. 

NOTE 2: Further clarification to the UE behaviour may be needed if the procedure in clause B.3. 2, i.e. time 

between transmission of Extended Service Request (3) and reception of RRC Connection Release (5) 
takes too long. 
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B.3.2 Procedures for leaving E-UTRAN 

The UE with dual Rx configuration is allowed to leave E-UTRAN in order to handle a CS call and/or perform 
registration signalling, and/or perform location management signalling, and/or sending or receiving SMS in IxRTT. 
When the UE needs to leave E-UTRAN it indicates this to E-UTRAN by using the Extended Service Request procedure 
with CS Fallback indication similar to how MT/MO calls are handed in clauses B.2.2, B.2.2a and B.2.3. The procedure 
is the same regardless what activity is performed in the IxRTT system (e.g. if it is a page response, MO call, re- 
registration). The procedure is shown in Figure B.3.2-1. 
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Figure B.3.2-1 : Performing IxRTT related activity for dual receiver UEs 

1 . UE is E-UTRAN attached the UE may also be registered in IxRTT CS. 

2. UE makes a decision that it needs to perform some IxRTT activity (e.g. in order to respond to an incoming 
IxRTT page, setup a MO call, perform location management signalling, or perform re-registration). 

3. UE sends an Extended Service Request (CS Fallback Indicator) to the MME. The figure shows the case the UE 
is in active state in E-UTRAN but the same principles applies if the UE is in idle state, TS 23.401 [2]. 

4. MME sends a Sl-AP message that includes: a CS Fallback Indicator to indicate the E-UTRAN to move the UE 
to IxRTT. 

5. The E-UTRAN triggers RRC connection release and continues with step 6. The E-UTRAN shall not include 
any redirection information towards the UE. 

6. E-UTRAN sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates that the SI 
UE Context Release was caused by CS fallback to IxRTT. 

7. MME sets the UE context to suspended status and sends to the S-GW a Suspend Request (IMSI) message that 
requests the suspension of EPS bearers for the UE. The Sl-U bearers are released for all EPS bearers by the 
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MME and all GBR bearers are deactivated. The non-GBR bearers are preserved and are marked as suspended in 
the S-GW. 

8. S-GW acknowledges the Suspend Request message and marks the UE as suspended. When a downlink data 
arrives at the S-GW, the S-GW should not send a downlink data notification message to the MME if the UE is 
marked as suspended. 

9. SI UE Context in the E-UTRAN is released as specified in TS 23.401 [2]. 

B.3.3 Procedures for returning to E-UTRAN 

The procedure for returning to E-UTRAN is the same as specified in clause 6.5. 
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